«

Hi,

I was trying to compile the following bit of code:

#include <iostream.h>

main(){

cout<<"Hello World!";

}

and I keep getting the following warning:

#warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section
17.4.1.2 of the C++ standard. Examples include substituting the <X>
header for the <X.h> header for C++ includes, or <iostream> instead of
the deprecated header <iostream.h>.

I tried replacing iostream.h with iostream but then I get the error:

test4.cpp:5: error: `cout' undeclared (first use this function)

Can anyone please tell me why this is happening? I am using Dev-C++
from Bloodshed Software to compile the code.

TIA.

mmu2...@gmail.com wrote:
> Hi,
>
> I was trying to compile the following bit of code:
>
> #include <iostream.h>

#include <iostream>
using std::cout;

>
> main(){
>
> cout<<"Hello World!";
>
> }
>

The difference between <iostream> and <iostream.h> is that the latter
places its contents into the global namespace, whereas the former
places its contents into the namespace "std." You should always use
<iostream>, and use one of several mechanisms for importing symbols
from that namespace for use. There are three basic mechanisms:

(1) Explicit qualification via the scope-resolution operator, e.g.:
std::cout << "Hello World!" << std::endl;
(2) A using-declaration for each member of the namespace you wish to
use, e.g.:
using std::cout;
using std::endl;
cout << "Hello World!" << endl;
(3) A using-directive, which brings an entire namespace into your local
scope (or global, if used globally. Please, don't do that!):
int main() {
using namespace std;
cout << "Hello World!" << endl;
return EXIT_SUCCESS;
}

(1) is often best if you only need to use a name once or twice. If you
need to use it more than that, it's usually best to go with (2) for the
sake of readability. There are some restrictions on where (2) can be
used, though. In particular, using-declarations inside a class scope
(but not within a function body) can only be used to expose names from
a base class (e.g. "using BaseClass::someIdentifier;").

(3) is worth considering if you're going to make heavy use of several
names from another namespace. However, it is hazardous. The most
important rule is never to use (3) at global scope. Use it at the top
of a function body, to avoid polluting the global namespace with an
unbounded number of symbols, most of which you are unlikely to be aware
of. Even if you're sure you know every single identifier in the STL,
other people maintaining your code are guaranteed not to.

HTH,
Luke

Luke Meyers wrote:

> The difference between <iostream> and <iostream.h> is that the latter
> places its contents into the global namespace, whereas the former
> places its contents into the namespace "std." You should always use
> <iostream>, and use one of several mechanisms for importing symbols
> from that namespace for use. There are three basic mechanisms:
>
> (1) Explicit qualification via the scope-resolution operator, e.g.:
> std::cout << "Hello World!" << std::endl;
> (2) A using-declaration for each member of the namespace you wish to
> use, e.g.:
> using std::cout;
> using std::endl;
> cout << "Hello World!" << endl;
> (3) A using-directive, which brings an entire namespace into your local
> scope (or global, if used globally. Please, don't do that!):
> int main() {
> using namespace std;
> cout << "Hello World!" << endl;
> return EXIT_SUCCESS;
> }

<snip advice about when to use which mechanism>

One more rule to add for the OP:
Never use (2) or (3) in a header. Always explicitly qualify the names.
Otherwise, everyone who ever includes your header, from now until the
end of time, gets the namespace pollution whether they want it or not.

Gavin Deane

Gavin Deane wrote:
> One more rule to add for the OP:
> Never use (2) or (3) in a header. Always explicitly qualify the names.
> Otherwise, everyone who ever includes your header, from now until the
> end of time, gets the namespace pollution whether they want it or not.

I'm not sure I agree with that. Perhaps you meant, never use (2) or
(3) outside of a namespace scope in a header? If I'm defining my own
namespace, it's reasonable in many cases to make use of a
using-declaration therein for a commonly-used class from elsewhere (for
example, if one is heavily using boost::shared_ptr). In rarer cases,
(3) may be somewhat acceptable, but it's probably indicative of some
design problems if you find yourself having to import another namespace
wholesale into yours.

Luke

Luke Meyers wrote:
> Gavin Deane wrote:
> > One more rule to add for the OP:
> > Never use (2) or (3) in a header. Always explicitly qualify the names.
> > Otherwise, everyone who ever includes your header, from now until the
> > end of time, gets the namespace pollution whether they want it or not.
>
> I'm not sure I agree with that. Perhaps you meant, never use (2) or
> (3) outside of a namespace scope in a header? If I'm defining my own
> namespace, it's reasonable in many cases to make use of a
> using-declaration therein for a commonly-used class from elsewhere (for
> example, if one is heavily using boost::shared_ptr).

Yes, I was intending to describe a particular case of using
declarations/definitions at global scope but I didn't make it clear.
Probably because my personal preference is to explicitly qualify names
all the time so the point you make never comes up in my mind. Thanks
for the correction.

Gavin Deane

I've been in an environment where some misguided folks adopted a deeply
nested namespace scheme which paralleled Java's package naming
convention. This travesty resulted in, among other things, the fact
that universal explicit qualification quickly reduced code to
illegibility. So, (2) is a decent coping mechanism for misfortune such
as that, until such time as the whole mess can be refactored.

Luke

On 2 Jan 2006 23:37:48 -0800 in comp.lang.c++, "Luke Meyers"
<> wrote,
>The difference between <iostream> and <iostream.h> is that the latter
>places its contents into the global namespace, whereas the former
>places its contents into the namespace "std."

Sorry, not true.

That's roughly what happened to headers adapted from old C.
But iostream was never old C, and iostream.h was never standard
anything. So iostream.h can be anything, but it most often is
whatever that vendor was using for streams before the committee made
up their minds. It often doesn't support std::string at all, and
sometimes cannot even be linked in the same program as <iostream>.
Nothing but trouble at this point.

wrote:
> Hi,
>
> I was trying to compile the following bit of code:
>
> #include <iostream.h>
>
> main(){
>
> cout<<"Hello World!";
>
> }
>
> and I keep getting the following warning:
>
> #warning This file includes at least one deprecated or antiquated
> header. Please consider using one of the 32 headers found in section
> 17.4.1.2 of the C++ standard. Examples include substituting the <X>
> header for the <X.h> header for C++ includes, or <iostream> instead of
> the deprecated header <iostream.h>.
>
> I tried replacing iostream.h with iostream but then I get the error:
>
> test4.cpp:5: error: `cout' undeclared (first use this function)
>
> Can anyone please tell me why this is happening? I am using Dev-C++
> from Bloodshed Software to compile the code.
>
As David Harmon has already pointed out, <iostream.h> is not part of
the C++ standard, and never was part of the official standard.
Some compilers like the GNU compiler, will post a warning message about
the header being deprecated. But what they're referring to is that
it's deprecated to the implementation. That means the GNU compiler
itself may not support this non-standard header file in the feature.
It doesn't mean it's deprecated by the offical C++ standard.

If you use a header that is deprecated IAW official C++ standard, then
your code would still be portable, because any fully compliant C++
compiler would have to support it until the standard completely removed
it.
A header that never was part of the official C++ standard is not
portable, because no C++ compiler has to support it.
You'll find more compliant compilers like VC++ 7.1, don't support these
non-standard headers at all.