cout and std::cout

What is the difference between cout and std::cout?
Thanks..

One uses the cout defined in whatever namespace you said you were using, eg.
using namespace std; would get you to std::cout

using namespace foo; would get you to foo::cout


If you use std::cout, you always get what you asked for.

Okay.. so if I want to use just cout, what namespace should I use?
Thanks for replying, Salem..

You should use it as std::cout unless you have a good reason for exposing the whole namespace.

>so if I want to use just cout, what namespace should I use?
It should look like this:

Code:

---

#include <iostream>

int main()
{
  std::cout<<"I'm using cout\n";
}

---

I prefer to use std::cout (and std::cin and std::string, etc). But many beginner programs use the using directive, which looks like this:

Code:

---

#include <iostream>
using namespace std;

int main()
{
  cout<<"I'm using cout\n";
}

---

My advice is to always add the std:: to your standard library names, but it's not that bad if you prefer this solution for small programs.

using namespace std;
is a convenient compatibility hack for old-standard C++ which didn't have any namespaces at all, and thus means you don't have to re-write the code to put std:: in front of everything.

But as your programs become more complex, and you start using multiple namespaces, blanket "using namespace" is a disaster waiting to happen.

You can (at a pinch) also write
using std::cout;
then write
cout << "Hello world" << std::endl;
if you want the convenience of the short-form for your most used members of the standard namespace.

Quote:

---

Originally Posted by Salem

using namespace std;
is a convenient compatibility hack for old-standard C++ which didn't have any namespaces at all, and thus means you don't have to re-write the code to put std:: in front of everything.

But as your programs become more complex, and you start using multiple namespaces, blanket "using namespace" is a disaster waiting to happen.

You can (at a pinch) also write
using std::cout;
then write
cout << "Hello world" << std::endl;
if you want the convenience of the short-form for your most used members of the standard namespace.

---

I kind of like this bit when writing stuff that does lots of output, so you can easily use cout << ... << endl; but it's still (fairly) clear which cout you intend to be used.

This resembles the model [if I remember right] that is used in for example Modula-2 where you specify which modules you want to take which function(s) from.

And of course, should you find that you want to use foo::cout instead of std::cout [say], you only need to make one change in the file.

[And you can of course still mix foo::cout and std::cout in the same source file].

But maybe that's just because I'm a bit lazy.

--
Mats

Quote:

---

Originally Posted by Salem

But as your programs become more complex, and you start using multiple namespaces, blanket "using namespace" is a disaster waiting to happen.

---

Whats a namespace anyways? Our school is retarded, we are taught C++ on Borland Turbo C++ 4.5 (some other noobs learn on the DOS version 2.x)...Only lately I started using the BloodShed DevC++ and Code::Blocks...and learnt the using namespace std; line, thinking it as a part of the new syntax >.> Same for void main/int main..whatever happened?

A namespace separates functions into there own scope so to speak.

Code:

---

namespace abc
{
    int getValue()
    {
        return 10;
    }
}
namespace qwe
{
    string getValue()
    {
        return "Hello";
    }
}

---

you can safely call the proper getValue depending on the namespace you choose to use

> Whats a namespace anyways?
Suppose you want to use a graphics library and a sound library.
Suppose that for some reason, they both implemented a function called Read().

In C and old C++, what results is a complete mess of multiply declared symbols, the wrong code being called, and general "wtf" all round. The problem could usually be solved, but it was always an improvised hack.

Originally, people who knew such things were bound to happen prefixed all their public symbols, so we ended up with SndRead() and GraRead(). But that was somewhat cumbersome to implement and things occasionally slipped through.

Namespaces provide an automatic way of generating these prefixes for the whole interface in one go, and gives you the flexibility of using the long or short form names.

So where you previously used SndRead(), you would instead use Snd::Read(), or having established a prior "using" clause, just Read()

Quote:

---

Originally Posted by Salem

In C and old C++, what results is a complete mess of multiply declared symbols, the wrong code being called, and general "wtf" all round. The problem could usually be solved, but it was always an improvised hack.

---

lmfao THAT would explain a lot...and any idea on the trend of the necessary int main? I mean, 'main must return a value', all that.

main() was specified to return int from day one (i.e. when C was first created, well before it was ever standardised). The C and C++ standards still require that compilers support main() returning int.

void main() is, and always has been, a non-standard extension support by some compilers. Historically, the vendors of a couple of those compilers attempted to influence the content of the standards, so their help files stated falsely that void main() is/was standard, and most of the code examples supplied by those vendors still use void main(). The standards have never adopted void main().

void main only ever came about because of crappy DOS, incapable of running more than one program at once, and having a shell which was utterly incapable of dealing with the exit status of programs.

Quote:

---

Originally Posted by Salem

void main only ever came about because of crappy DOS, incapable of running more than one program at once, and having a shell which was utterly incapable of dealing with the exit status of programs.

---

If DOS can't deal with program return codes, then how does the ERRORLEVEL variable in batch files get its value?

s/utterly incapable/real pain in the ass/