cout vs std::cout

[Mark Casternoff]

I'm getting back into C++ after a long hiatus (they didn't have
namespaces back then).

I know this question is completely subjective, but I'd be interested in
hearing which is
the "better" style and what the pros and cons are (I'm using cout as
example, but it really
applies to any similar construct):

1) using std::cout;
cout << "This is a test";

2) std::cout << "This is a test";

The difference being prefixing every cout with 'std' or declaring it
ahead of time. The second
method could be used if cout existed in more than one spot, but how
often is that an issue?

I've seen both methods in code, but I'm seeing #2 a lot more frequently.

[microcassanova]

just jumping in to thward my nose into wallstreet of c++ not to get
broken .

reasons are
1. using namespace std is not good as lot of people in this thread
aldready mentioned . why ?

assume you have 2 functions with same name may be fool() within
namespace std and fool() outside wihtout any namespace .
using namespace std
fool() --always triggers fool() inside namespace

During your code at later stage you want to call other fool() outside
of the namespace then also fool() inside std namespace gets
trigered . you should use extra ::fool() to overcome this problem why
allthose nasty blunders .

better use std::fool() wherevr u need . hope my nose not broken in c++
wall street. :)

[Pawel Dziepak]

microcassanova wrote:

reasons are
1. using namespace std is not good as lot of people in this thread
aldready mentioned . why ?

That's why you should think before you write any piece of code. I doubt
if creating function (or class or method or whatever) with the same name
as something in std namespace is a good idea. However, if you really need
to do this, then it is, in fact, better not to use "using namespace std"
everywhere.

In small programs it isn't a problem to help yourself and put using
namespace std on the top of the file. If you are working on a big
project, you have to think what you are doing and remember that:
std::cout << "blah";
is always safer than:
using namespace std;
....
cout << "blah";

Pawel Dziepak

[Hendrik Schober]

Pawel Dziepak wrote:

microcassanova wrote:

>reasons are
1. using namespace std is not good as lot of people in this thread
aldready mentioned . why ?

That's why you should think before you write any piece of code. I doubt
if creating function (or class or method or whatever) with the same name
as something in std namespace is a good idea. [...]

Whoa. Why should you ban yourself from using identifiers like
'list', 'vector', 'sort', 'min'...

Pawel Dziepak

Schobi

[Juha Nieminen]

Hendrik Schober wrote:

Whoa. Why should you ban yourself from using identifiers like
'list', 'vector', 'sort', 'min'...

Not to talk about the more obscure function names in the standard
library, many of which the programmer might have never heard of. Just
browse <algorithmor <functionalor any of the other standard headers
for many examples.

[Pawel Dziepak]

Hendrik Schober wrote:

Whoa. Why should you ban yourself from using identifiers like 'list',
'vector', 'sort', 'min'...

I didn't say that it is forbidden or something like that. I think that
just for your own good you should consider choosing another identifiers.
However if you like thinking if that "cout" stands for "std::cout" or
"myown::cout" than I see no reason why to "double" identifiers.
Everything depends on kind of project you are developing. For example, if
it uses only its own version of lists, vectors, etc. it's normal that you
don't create any "strange" names. However, if you sometimes use std::list
and sometimes myown::list, then, together with "using namespace x" you
can do something bad.
If code is easier to read and understand, there is smaller chance of
making stupid mistakes.

Pawel Dziepak

[Jerry Coffin]

In article <gc**********@cb.generation-online.de>, sp******@gmx.de
says...

[ ... ]

As I recall, the editing to fix the code actually took less time than
the re-compilation...

:)

(Implementing a bunch of std lib containers so that they have
less errors than bought ones isn't something most of us finish
on a sunny Sunday afternoon.)

The quick part was changing the code so it used the containers in the
standard libary (after it was fixed) instead of my replacements. The
replacements themselves did take just a bit longer (though my
recollection is that implementing them wasn't quite as much work as I
expected either).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <pa*********************@quarnos.org>, pd******@quarnos.org
says...

[ ... ]

That's why you should think before you write any piece of code. I doubt
if creating function (or class or method or whatever) with the same name
as something in std namespace is a good idea. However, if you really need
to do this, then it is, in fact, better not to use "using namespace std"
everywhere.

One of the reasons for putting the standard library into a namespace is
that you don't (and in general _can't_) know all the names it might
define. As such, you might have duplication even if you avoid all the
names you know about.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Pawel Dziepak]

On 7 Pa¼, 04:39, Jerry Coffin <[e-mail]:

One of the reasons for putting the standard library into a namespace is
that you don't (and in general _can't_) know all the names it might
define. As such, you might have duplication even if you avoid all the
names you know about.

It won't be a problem. Not using the same names is a hint that can
make understanding the code easier. It's definitely not a rule.
Everybody write codes in a way they like the best and I would just
think for a moment before using the identifier I know that is used in
standard library. Namespaces solves almost all problems with
conflicting names, but overusing "using namespace x" make is a bit
pointless.

Pawel Dziepak

[Yannick Tremblay]

In article <gc**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>Yannick Tremblay wrote:

>In article <gc**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>>Yannick Tremblay wrote:

In this case, "String" might be acceptable but this a only the first
step on a slippery road. Be careful or the namespaces created by
worse programmers than yoursel will start ressembling hungarian
warts.

Don't you think that a bunch of programmers who decide
that they generally want to explicitly spell out every
namespace name for every identifier have a typing pain
threshold high enough to not to shorten names beyond
usability?

"Worse programmers than yourself". By virtue of intelligently
participating in a philosophical discussion about probgramming and by
virtue of participating in drawing up a code guideline document, I
would conclude that you are well above average as a developper.
Coding guidelines are arguably almost redundant for a good programmer
(apart from agreeing on minor stylistic standardisation like CamelCase
vs under_scored). Coding guidelines are at their most important for
below average programmers. So the peoples that agreed on the above
will most probably do the right thing and take a sensible decision on
naming. I have no problem with that. It the new graduate, I am
concerned about.

Slightly related issue: one of that my (many) issue with
(pseudo-)hungarian notation is that it tend to make identifiers more
cryptic. IME, the average lenght of identifiers stays about the same,
it's just that characters that would have been used for the
descriptive name are instead used for the (pseudo-)hungarian prefix.
Yan