Does gcc with different version include some different default header files?
 

Hi,

I have a question about header file.

test.cpp:

the code above use strcpy and atoi, they are in string.h and stdlib.h, but I didn't include these, and just include <string>.
It can be compiled correctly by gcc4.1.1(fedora6) and MSVC6(windows2003), but wrong with gcc4.6.0(fedora15).

Is there a way to make gcc4.6.0 compiling the code correctly?

thanks.

You should refer to the man-page for specific information as to which header files should be included.

For strcpy(), you should include cstring (not string.h, since this is applicable to C, not C++).

For atoi(), you should include cstdlib (not stdlib.h)


P.S. In C++, there's little use for strcpy(). Use the string class instead when defining a string. As for atoi(), it too has issues. If the input is invalid (ie. non-numeric), atoi() returns zero. This could be interpreted by the program as a legit number. Consider using stringstream instead; it provides the ability to query whether the conversion from a string to a number was successful or not.

Thanks, you let me know more knowledge about c and c++.

the test.cpp is just an example to point out that on some verion of gcc it's correct and some are wrong.

I have some project compiled correctly on fecora6, but cann't be compiled on fedora15, the main resean is that there doesn't specify correctly header file as in test.cpp.

As dwhitney67 pointed out, you should always check the manpages. I've had C code that compiled for years across different distributions and then suddenly stopped compiling because a secondary include was different in a different libc version. I'd forgotten to include the correct header, but since another header had included the one I needed I never noticed. I've also downloaded open-source projects that wouldn't compile because of missing includes, most likely because of this very issue. A bad habit of mine is to guess the headers for functions I use a lot and if it compiles I leave it.

On a separate note, you've inadvertently written a C program, except for the C++ header. You might therefore consider playing around with C rather than making what you've written proper C++. I became very proficient with C++ before I learned C, but I certainly prefer C if I don't need complicated data structures. I've also used C++ compilers where some of the standard C functions were in namespace std, which is a mess! I think the committee for the C++ standard just included things like <cstring> because they didn't want those "archaic" .h includes, but if you're using C functions you either can't do it in C++ (e.g. fcntl) or you're just not using the C++ symbol meant to replace it. In either case, you might as well just include the .h and make it proper C!

As far as what you've written, strncpy should be used instead of strcpy because it can prevent a buffer overrun if your source string is longer than you anticipated. Lastly, strtol replaces atoi and is a more recent function.
Kevin Barry

PS The differences between C and C within C++ aren't as arbitrary as they seem on the surface. You can run into some serious linking issues with C++, even if the code you've written is 100% C.

Thanks to dwhitney67 and ta0kira.

maybe due to my ugly engish, you have some mistake of my purpos.

at last, I find <cstdlib> and <cstring> are included by <string> indrectly in MSVC7. this must be why the test.cpp can be compiled correctly. and in new version of gcc, they are not included by <string> indrectly.

thank you very much.

@cplus:

C++ and C are different languages. Any claim of C++ being a superset of C is incorrect. C++ originated as an offshoot of C, but has since diverged, and is a completely separate, different language nowadays. Both are actively developed, albeit by different people, and standardized in totally different documents.

When mixing C and C++ code, it is very important to do it correctly (using the well-documented patterns and guidelines), or you will end up with fragile or buggy code. Just because it compiles, does not mean it will work as intended.

You can compile most, but not all, C code with a C++ compiler, but the end result will be different to what you get if you used a C compiler. For example, compare the dynamic libraries the final binaries depend on using the ldd command. What is more important, is that the two binaries will have different runtime behaviour, especially with respect to memory management and exception and signal handling.

Most compilers today are actually compiler suites, with a number of "frontends" for different languages -- typically C, C++, and possibly one or more varieties of Fortran. Therefore selecting a different compiler is usually just a matter of different compiling options. I guess that can be confusing.

C and C++ compilers do both have small libraries built-in. These include for example strcpy(), strncpy(), memset(), memcpy() and memmove() functions; I haven't looked for an exhaustive list -- but it quite likely varies from version to version. These are all defined in the standard, and therefore do not really need a separate header file; think of these as having a header file built-in to the compiler.

While GCC does prefer its own implementation, you can tell it to not do that by using the --fno-builtin-function option, where function is the name of a function. (If GCC does not have its own version of the function, the option is ignored.) You can access the GCC implementation of these functions using __builtin_function().