Why iostream is No Longer Included as a Header File in C++

First of all I have gone through this question Why is #include <iostream.h> bad? and there the reason was simply that it is outdated but I personally think that as a header iostream was better cos you don't have to declare objects like cout and endl in global scope cos they were already in global scope and moreover since # is not used anymore that means it does not comes under a pre-processor directive. I just need to know that why was this done? I still use turbo sometimes and am comfortable in using it in c++ programs even though gcc and g++ provide better debuggers and everything.

Best Answer

I think you misunderstood the question. It's bad to include iostream.h because nowadays you should be using iostream. iostream.h is out of date, #include-ing it simply means that your code may or may not break, or shoot monkeys out of your nose, it's implementation defined.

Moving to iostream is simply moving to the standard version. You get the guarantee of it working, having an exception aware API, better localization, etc, etc.

Also, you don't want all of std dumped into global namespace. There is tons of stuff in there that you don't want to know about. Typing those 5 extra characters prevents weird errors if you have a class called map or something.

That being said, if you really want to use C++ as it was before 1998, have at it. But you're throwing away community support (The C++ community has moved on), updates, and any modern innovations from the last 1.5 decades. I think these outweigh the only downside I see, learning a few new things about how C++ has changed.

Related Solutions

C++ – Document Functions in Header or Source File?

My view...

Document how to use the function in the header file, or more accurately close to the declaration.
Document how the function works (if it's not obvious from the code) in the source file, or more accurately, close to the definition.

For the birds-eye thing in the header, you don't necessarily need the documentation that close - you can document groups of declarations at once.

Broadly speaking, the caller should be interested in errors and exceptions (if only so they can be translated as they propogate through the layers of abstraction) so these should be documented close to the relevant declarations.

C++ – Common header file for C++ and JavaScipt

I had proposed a quite similar approach here: https://stackoverflow.com/questions/4248831/shared-config-file-between-php-and-c/4248881#4248881 for a similar issue.

I would suggest to write a small script that generates code for C++ and JavaScript, with the configuration you want to have common. You can also use two templates in a template library, that you will run as part of your build process that will generate the appropriate files for each language.

Using a freemarker-like syntax (although I do not suggest including another language!), there could be something like this for JavaScript:

commonStuff = { config1: ${value1},
config2: ${value2}
}

and another template for the C++ implementation.

As suggested in the comments below, one good candidate for that, is to use sed, so that you would not have to introduce another language since your project has two already.

Best Answer

Related Solutions

C++ – Document Functions in Header or Source File?

C++ – Common header file for C++ and JavaScipt

Related Topic