C++ Header Inclusion

[Matthew Burgess]

According to 17.4.4.1 paragraph 1 in the standard "A C++ header may include
other C++ headers." This gives rise to what I consider to be a portability
problem, albeit trivially corrected. Consider this code that compiles
correctly on Sun's Forte 7 compiler:

#include <string>
int main() {
std::string text = "34";
std::atoi(text.c_str());
return 0;
}

Obviously, std::atoi comes from the <cstdlib> header which, due to the lack
of compilation errors one can assume is #included within <string>. I have a
feeling that other implementations may not see a requirement for <cstdlib>
features in their implementation of std::string and therefore the code will
require fixing if it is to be ported to such an implementation.

My question therefore is: Is there a need for the standard to include some
kind of safeguards to aid in portability, e.g. state that a compiler warning
be generated in the event that such a scenario as described above may occur?

Regards,

Matt.

 

[Attila Feher]

According to 17.4.4.1 paragraph 1 in the standard "A C++ header may
include other C++ headers." This gives rise to what I consider to be
a portability problem, albeit trivially corrected. Consider this
code that compiles correctly on Sun's Forte 7 compiler:

#include <string>
int main() {
std::string text = "34";
std::atoi(text.c_str());
return 0;
}

Obviously, std::atoi comes from the <cstdlib> header which, due to
the lack of compilation errors one can assume is #included within
<string>. I have a feeling that other implementations may not see a
requirement for <cstdlib> features in their implementation of
std::string and therefore the code will require fixing if it is to be
ported to such an implementation.

My question therefore is: Is there a need for the standard to include
some kind of safeguards to aid in portability, e.g. state that a
compiler warning be generated in the event that such a scenario as
described above may occur?

This is not really possible to solve with the file/inclusion model. To
overcome this one either needs to use a lint checker. And you do not really
want to lint your code each time you compile it. So puting it into the
compiler by the standard would be an overkill.

A "module" based approach could solve such issues, but then again (IMHO)
that would also be too big change for the language. :-(

 

[Mike Smith]

According to 17.4.4.1 paragraph 1 in the standard "A C++ header may include
other C++ headers." This gives rise to what I consider to be a portability
problem, albeit trivially corrected. Consider this code that compiles
correctly on Sun's Forte 7 compiler:

#include <string>
int main() {
std::string text = "34";
std::atoi(text.c_str());
return 0;
}

Obviously, std::atoi comes from the <cstdlib> header which, due to the lack
of compilation errors one can assume is #included within <string>. I have a
feeling that other implementations may not see a requirement for <cstdlib>
features in their implementation of std::string and therefore the code will
require fixing if it is to be ported to such an implementation.

Well, the better rule to follow is that if *you* use <cstdlib>, you
should include it, regardless of whether it is used by <string>.