Printable View
I wrote a little test program using numeric_limits, but forgot to include <limits>. It compiles anyway without complaints using GCC 4.1.1. I tried using the -ansi and -pedantic options with no effect. Why is the compiler allowing this, and are there tools available in Linux for testing the code more strictly?
some of your other headers included it
Hmm.
Could you post the little test program?
You aren't doing something silly like using namespace std;?
The following should have
but compiles without it.Code:#include <limits>
Code:#include <iostream>
int main() {
std::cout << "Maximum value of float is " << std::numeric_limits<float>::max() << "\n";
std::cout << "Maximum value of double is " << std::numeric_limits<double>::max() << "\n";
}
Hm.
My gcc seems to have <iostream> #including <istream> which happens to #include <limits>.
An artifact of that, no doubt. But I don't know whether or not the standard guarantees such behavior. A number of things are left to the programmer.
if you don't include anything, it will give an error; to show that it indeed does complain
Code:int main() {
return INT_MAX;
}
If the standard requires that...
It seems somewhat implicit that <limits> is #included.Quote:
basic_istream<charT,traits>& getline(char_type* s, streamsize n);
23 Returns: getline(s,n,widen(’\n’))
basic_istream<charT,traits>&
ignore(int n = 1, int_type delim = traits::eof());
24 Effects: Extracts characters and discards them. Characters are extracted until any of the following occurs:
— if n != numeric_limits<int>::max() (18.2.1), n characters are extracted
— endoffile
occurs on the input sequence (in which case the function calls setstate(eofbit),
which may throw ios_base::failure (27.4.4.3));
But I don't' know C++ that well.
I guess the more general question is, is the exact way that standard headers are #include'd in each other guaranteed by the standard? If not, then there needs to be a lint-like tool to check the headers.
I think you should bring this up with Bjarne Stroustup (*check spelling)
AFAIK, there is no specific requirement in the standard that standard headers either #include each other, or that they avoid #include'ing each other.
However standard headers specify relationships between types or objects in header files (eg <iostream> includes a declaration of cin, which is an object of type istream, which is a type declared in <istream>). One way of ensuring that the standard headers don't break "one definition rule" would be for them to #include each other. This is probably what has been done with gcc, and explains what is happening. Another way would be for the headers to employ "compiler magic" to ensure things work as intended; with such a compiler, the original code would probably break unless all the required headers were explicitly #include'd.
Which comes back to a basic guideline: if you are using the standard library, #include all the headers that correspond to the features you are using. The standard does specify that all standard headers can be safely #include'd more than once, so if there are interdependencies, you won't be hurt by following such a guideline.
It's Bjarne Stroustrup.
That's my intent, but it's just too easy to forget to #include some of them, and then, when the compiler doesn't complain due to indirect #include's, to think that I've written standards-compliant code, give it to someone else, and be embarrassed when they can't compile it. Anyone know if there is something lint-like for checking this?Quote:
Originally Posted by grumpy
I suppose one way of doing it is to deliberately write headers that don't use any internal #include's not required by the standard. If the code compiles using those, then it's okay.
PC-Lint detects missing headers even taking into consideration dependencies. That's the only lint I use though... so I dunno about others. You can also gain some quick insight into GCC standard header dependencies implementation by compiling with the -H switch which will list all headers used.
Regardless, the number of headers that should be included is not that big.
> I suppose one way of doing it is to deliberately write headers that don't use any internal #include's not required by the standard. If the code compiles using those, then it's okay.
I think you are taking this header thing a little too far. Header dependencies are not something that works against you. Missing a <string> is certainly not nice to see, but that's your responsibility. Not something that you can blame on how the compiler implements header dependencies. It does so because it needs those dependencies. Much the same way you implement your own header dependencies in your code and can't expect to be blamed if someone else doesn't include the correct headers.
The problem here is solved not by knowing how your compiler implements the standard library. It is solved by you studying the standard library and knowing which headers it uses and where its objects and functions are located.
I disagree - if it's possible for something to be automatically checked, then ideally it should be done. Sure, it's possible in theory to never make a mistake in including the right headers, just like it's possible to write object-oriented code in C. A particular compiler may need certain header dependencies, but if the standard doesn't require them, there should (ideally) be checking to make sure they aren't hiding omission of generally required headers.
I think a simple way to check is to search the source file for strings associated with particular header files and then check whether the header is actually included - for example, if it contains "numeric_limits", then <limits> should be included. I'm not sure if this scheme could be made completely reliable, but programs like lint already flag a lot of perfectly good code so it shouldn't be any worse than that. This is basically what a programmer does - there's a mental map between tokens and header files. Less experienced ones just haven't committed the whole map to memory yet.
Edit: I think that if there exists an algorithm to determine for certain whether a particular type of mistake has been made, then ideally the compiler should implement it. Programs like lint should only be used to check for things that _may_ be mistakes.
I disagree with your last statement, robatino. The compiler should only perform checks that can be performed with reasonable performance. Checking that every required standard header comes with quite an impact: the compiler must have a list of standard headers and symbols from there, and it must check for every symbol whether it could come from the standard library and if it does, whether the appropriate header has been included. It must also make the distinction between usages that require full definitions and those where declaration suffices, mostly because of the <iosfwd> header. Seems like a lot of additional effort to me.
As such, this test should be automated, but performed by an external tool or enabled by a compiler switch.
You're right - if there is a large performance hit, it's better to have the test done separately. The tool wouldn't have to be used except just before releasing code, since during the debugging process on one's own machine the "missing" headers wouldn't make any difference.
I would like to add the problem of distinction between headers. It's obviously quiet common for header files to include other header files (we wouldn't be discussing it otherwise). The "nested" header file may declare the specific object we are using at a certain point, however, it's inclusion may not make much sense since the "main" header inclusion is already there, and possibly more meaningful.
How would a compiler know the difference? It's best for a third party tool like lint software to do this job.
How would a 3rd party tool know the difference?
Obviously this only works for system headers that have a headercontents.conf (or whatever) supplied, no matter which tool does it.
The third party tool wouldn't know the difference either. However, it wouldn't bog your compiler with erroneous warning messages. Something that a compiler shouldn't do.
Erroneous warning messages? What's erroneous about "Your program does not comply with the C++ standard and might not compile on other compilers."?
I don't think I expressed myself correctly.
Point 1.
The issue of header dependencies is even more prevalent in non standard headers. Boost, for instance, is known to provide "frontend" headers for a number of its libraries. And we as users also use similar techniques, or any others we can think of. The compiler could only really do this check for standard headers, limiting its usefulness, and forcing the parser to match names against a table of allowed names, limiting its speed.
Point 2.
When will this check be made? Correct me if I'm wrong, but not at the pre-processing stage where names are not checked. During compilation the headers are already included, so no warning could be issued since the names are already in scope. Unless the pre-processor left some markers for the compiler to interpret...
Point 3.
One little thing that can be solved by "know your libraries" (one of the commandments of good code), will increase considerably compile times. Even if seen as a switch we can use or not, this type of test couldn't really be used on a big project where it would make the most sense, without an impact on productivity.
Point 4.
How many warning messages are too many? In other words what will flag the warning? I suppose a reference being made on the code to a name that is only being defined on a "inner" header. What if I make 30 references to that name on a single unit? What about other units? Do we limit to 1 warning message per unit? Does it make sense? What about 15 different names on a single unit? And what about other units? This "little", "helpful", "innocent", and "useful" check would have the potential to quickly fill my maximum error messages limit and cancel compilation with more important warnings or errors being left out.
Quiet frankly, the solution is to know the standard library. Or to use external code parser like lint tools.
All in all, using a name declared on an "inner" header file is not an error, is not even worth a warning. It is a standard practice. Be it a standard library name or not. Maybe it's shocking if it's a std::string being used through <iostream>, I agree. But certainly it's much less shocking if it's NULL being used through <stdlib>.
Know your library.
is it a standard that the header should be included?
Yes, of course. A name that hasn't been defined is a compile-time error.
Where that header is included is a different matter altogether. If directly through an include directive, or indirectly through header dependencies is left for the programmer to decide. Common sense and good programming practices should dictate that, particularly on standard headers, the header where a given name is declared should be directly included. It eases portability.
In particular, one should never rely on any headers that are not part of the current project to include anything else, unless they're explicitly documented as doing so.