LinuxQuestions.org - incomplete type error using cpp with gcc

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - incomplete type error using cpp with gcc (https://www.linuxquestions.org/questions/programming-9/incomplete-type-error-using-cpp-with-gcc-596919/)

incomplete type error using cpp with gcc

Greetings,
I have an issue when compiling a program in cpp. The specific error is:
test.cpp: In function "int main()" :
test.cpp:11: error: aggregate "std::string value" has incomplete type and cannot be defined

I'm using Fedora Core 7 with kernel-2.6.21-1.3194.fc7 and I'm using gcc-4.1.2-27.fc7. I'm compiling the following program with the command:
gcc -o test.exe test.cpp

Any clues would be greatly appreciated.

Code:



#include <stdio.h>

#include <vector>

#include <string.h>

using namespace std;



int main()

{

        printf("Hello World!\n");

        std::string value;

        value = "Hello World";

        return 0;

}

Quote:

Originally Posted by aatwell (Post 2947177)

I'm compiling the following program with the command:
gcc -o test.exe test.cpp

Any clues would be greatly appreciated.

Clue: gcc compiles C programs, g++ compiles c++ programs.

Also, in C++ programs when using C headers, one usually prefixes the name with a 'c' and drops the '.h', so for example <stdio.h> becomes <cstdio>.

<string.h> is a C header which should not include std::string. You need the C++ header, which is <string>.
ta0kira

For that simple program though, you don't need to include <string>. If you were using some function like substr() or something, then you'd need it.

Quote:

Originally Posted by Nylex (Post 2947279)

For that simple program though, you don't need to include <string>. If you were using some function like substr() or something, then you'd need it.

…huh? I agree the program is simple enough for lines 9 and 10 to be omitted (since they don’t do anything). But since line 9 is how it is, you need to #include <string>.

This should work:

Code:

#include <iostream>

#include <vector>

#include <string>

using namespace std;



int main()

{

        std::string value = "Hello World\n";

        cout << value;

        return 0;

}

Quote:

g++ -o test test.cpp

Quote:

Originally Posted by osor (Post 2947311)

But since line 9 is how it is, you need to #include <string>.

It compiles and runs fine without "#include <string>" (on my machine with gcc 4.1.2, anyway).

Quote:

Originally Posted by Nylex (Post 2947563)

It compiles and runs fine without "#include <string>" (on my machine with gcc 4.1.2, anyway).

First and foremost, even if it does, it’s wrong. There is nothing special about strings that allows their use without their definition, and their is nothing special about namespace std (in fact, namespace std does not exist without the standard library headers). See §17.4.2.1.

Second, are you sure? Whose gcc do you have? For me, it throws an error with (and most of these are near-vanilla) g++-3.4.6, g++-4.1.2, and g++-4.2.2.

Also, there is a separate issue (probably) not present in the original post. When you #include certain standard headers, they end up including others. This behavior is expressly permitted by the standard (§17.4.4.1). The only problem is it is not specified what headers include other headers except that a header must include another header if it contains a needed definition. So free rein is given to implementors on what headers can include what other headers. For example, with most g++ implementations, if you #include <iostream>, you have implicitly #included <string> as well. Except for the unlikely event that your <vector> header #includes <string>, I don’t see how your implementation successfully compiles the original program. This gets to limit the portability of compiling a program, since some implementors chose differing headers to be included by other headers. As such, the next version of g++ (4.3 branch) will strive to eliminate all unnecessary headers inclusion of other headers. If that happens, a program which successfully compiles with g++ will be guaranteed (at least in that respect) to compile on any other conforming compiler.