Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I was reading another thread where a guy asked about C++ books for beginners, and one of the programmers answering wrote this:
Some warnings: avoid all books that present an "hello world" stating with
#include <iostream.h>
I opened my C++ book and sure enough it included the iostream header like the example above.
Why is that bad? What other pointers should I keep in mind when learning C++?
Background: I am proficient with C and I'll start to learn C++ this next semester.
The header iostream.h is a non-standard header and does not exist on all platforms. As a matter of fact it does not exist on my system (using g++ and the GNU libstdc++). So any code using it would simply not compile on my system.
The iostream.h header used to be common before C++ was first standardized in 1998. But since the 98 standard used <iostream> instead of <iostream.h>, the latter has fallen out of favor (being non-standard and all) and is no longer supported on all platforms. Code that uses it should be considered non-standard legacy code and is not portable. Books that teach it should be considered outdated and avoided.
#include <iostream.h> is a sign that the book was written prior to the first C++ standard in 1998 (the standard header is iostream).
The problem is that older C++ code tends to be written in ways that are considered bad practice today. In particular,
std::string and std::vector.close functions rather than RAII.iostream.h isn't the worst thing a pre-1998 book will get wrong, but it's likely to be the first thing that a pre-1998 book will get wrong.
Maybe this comes a bit late but for what it's worth, on a unix/linux box do ls /usr/{local/,}include/c++/* or similar, according to your layout and paths. You could pipe to grep looking for the header in question, like:
ls /usr/{local/,}include/c++/* | grep iostream
This entails a look-up for iostream.h as well as any other superstrings.
Or run find / -type f -name iostream 2> /dev/null | grep include or locate iostream | grep include (provided the database is current, otherwise prepend with a call to updatedb)--these, however, will print also non-system-wide includes, so please adjust appropriately.
The actual C++ include path is easily found with something like:
g++ -v 2>&1| sed -rn 's/.+gxx-include[^=]+=([^ ]+).+/\1/p' # adjust iff empty
Equivalently on Windows and other machines. I guess the idea is clear--such a file as iostream.h doesn't exist in the system include path by default any longer, you still, however, can find legacy libc++ distributions with iostream.h either soft-linked to iostream or as its copy. So this is not a matter of style but rather of the circumstances. You could ship your own iostream.h with your project just make sure it's contained in the include path where your compiler looks up for the <...> headers.
Just dropping my 2 cents. I don't think there is a correlation between ".h" and the quality of a book. This is a minor syntax issue. Back in the day it was actually the correct sytnax.
Is it possible to have a great book with iostream.h? yes
Is it possible to have a terrible book with iostream? yes
I would rely on online user reviews (and my own review after reading) to judge the quality of a book.
cstdio, notstdio.h(the latter is deprecated).<cstdio>is guaranteed to provide the names innamespace stdis reason enough for me to prefer it. I know that it might also provide them in the global name-space just as<stdio.h>might provide them innamespace std. It is also a matter of consistency if you make it a habit to always use the<c…>headers. And for some headers, you'll really want this because they enhance the C interface with additional function overloads, for example.