|
From: Ioannis V. <no...@ho...> - 2002-06-08 02:45:30
|
> -----Original Message----- > From: dev...@li... > [mailto:dev...@li...] On Behalf > Of Mac Reiter > Sent: Thursday, June 06, 2002 12:00 AM > To: Dev-C++ User Mailing List > Subject: Re: [Dev-C++] #include <ios> > > > Daniel: > > The <ios> header is generally not needed, and should have > been included by > other iostreams headers. I suspect that the GCC or MinGW > people simply > removed the standalone header, or perhaps it is present but > can only be > found if you specify <ios.h> instead of just <ios>. (The <ios.h> is > *purely* a guess and I haven't run any checks at all). Since > Dev-C++ is > "just" the editor/debugger/project manager, and it uses the GCC/MinGW > toolchain for actual compilation, these kinds of issues will depend > entirely on how the GCC/MinGW tools work. > <ios> is needed when you want to use the facilities icnluded in it. You can not depend if a header file is included in another when not defined by the standard (if you wat the code to be portable, not even among different compilers and platforms, but even to the next version of your favorite compiler). You *must not* care about implementation details inside your code, and certainly not connect your code with them. It is the compiler's job for what headers it #include s inside other header files. > Microsoft's take on <ios> is given in the following MSDN article: > > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/vcstdlib/ht > ml/vclrfios_header.asp > > Basically, you could simply remove the <ios> line entirely, and both > compilers would be happy and you wouldn't need the > preprocessor commands > ("ifndef", etc). I'm gonna guess that the book was written > some time ago, > some of the C++ standards changed along the way, and not all > of the sample > code got updated. No the book is ANSI C++ compliant (at least as far as i know, and C++ god approves it, and god only approves excellent ANSI C++ compliant books). > > **IMPORTANT NOTE FOR NEW C++ PROGRAMMERS ** > Also, there is no such thing as an "ANSI C++ compliant > compiler" Of course there is. Try Intel C++ compiler for example. > -- *all* > current compilers fail the conformance tests in various ways. Not all. And standard conformance is increased day by day to the rest compilers too. Camaeu is another 100% conformant compiler too. And there are probably others too (perhaps GCC 3.x is 100% compliant too). > This means > that sample code inevitably needs to be modified for > different compilers. Things are improving day by day. The standard is very recent (late of 1998) for *everything* to be implemented immediately. And C++ is a multiparadigm language, that means it is like 4+ languages together (4 paradigms and many space/time efficiency concerns since it is intended for mission critical applications too (OSes, etc). > "Portable" code, for the time being, requires preprocessor > directives like > the one shown to change the code based on which compiler is > being used. No. Simply you code for the compiler you intend to use thinking of full ansi C++ and then if something does not compile, you change it with something that does. If you write a library or something and you care for many compilers out there, i wouldn't care but code as freely as i can knowing that since things are improving day by day everything will be soon ok for them too. That is, i can't think of an occasion why i would need #ifndefs for portability, and i can't think for any possible reason to do so. #ifndefs are used to make portable code using compiler extensions not for ANSI C++ code.Ioannis I think you have confused ANSI C++ code with system specific code (e.g. Win32 library calls). * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |