C++ Header Inclusion

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.

re: C++ Header Inclusion

Matthew Burgess wrote:[color=blue]
> 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?[/color]

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. :-(

--
Attila aka WW

re: C++ Header Inclusion

Matthew Burgess wrote:
[color=blue]
> 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.[/color]

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

--
Mike Smith