[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

cout vs std::cout

Mark Casternoff

9/28/2008 7:23:00 PM

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.

63 Answers

ram

9/28/2008 7:41:00 PM

0

Mark Casternoff <mac@foobarnet.org> writes:
>1) using std::cout;
> cout << "This is a test";
>2) std::cout << "This is a test";

I believe the majority of programmers is using style 1.

I prefer style 2, precisely, I prefer:

::std::cout << "alpha";

Reasons:

This code segment has a context-independent meaning
to the maximum extend possible by such a segment:

It can be copied from one source file to another
without the need to copy a using declaration, too.

It can even be copied into

namespace example { namespace std {} void example(){ ... }}

and still retain its meaning.

ISO/IEC 14882:2003(E) is using »::std« once,
»static ::std::locale::id« in 22.1.1.1.2.p1.

Hendrik Schober

9/28/2008 8:01:00 PM

0

Mark Casternoff wrote:
> 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.

Here's my EUR 0.02:
I have heard lots of complaints that #2 produces longish, unreadable
code from people who shy from it and never used it.
OTOH, I have used #2 for about a decade now and worked on projects
where it was required that /all/ identifiers have to be within some
namespaces and that /all/ identifiers are to be addressed with their
fully qualified name. So I /know/ that it isn't hard to read code
which fully qualifies all identifiers after a short while of looking
at such code (that's a "short" as in "weeks" or "months"). And this
isn't only my personal POV. Most of the time I worked under the rule
that using declarations (and even using directives!) where allowed
within any local scopes not bigger than a function, but this was
rarely ever used by anyone (with "rarely" meaning "far less than 1%
of the project's code"). I suppose that was because, after a short
while, people who really tried to work that way liked code better
that used fully qualified identifiers. (I abhor code that uses a
naked 'list' beside a naked 'cout', as I have no idea whether that
is 'std::list' or some other identifier.)

What I've learned, though, is to avoid creating namespaces which are
long and hard to type right even after weeks ('StringUtility') of
usage. :)

HTH,

Schobi

blargg.h4g

9/28/2008 8:53:00 PM

0

In article <2008092815231175249-mac@foobarnetorg>, Mark Casternoff
<mac@foobarnet.org> wrote:
> 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";

Code written using #1 is more interdependent, since the cout line depends
on there being a using line earlier. On the other hand, it can be more
readable. Use of "using" in source files is mostly a style issue. Use of
#1 in header files is generally a bad idea, especially at global scope;
use #2 in header files unless you have a good reason not to.

Matthias Buelow

9/28/2008 9:04:00 PM

0

Mark Casternoff wrote:

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

It's because many C++ programmers prefer long-winded bureaucracy over
conciseness or even (shock!) simplicity. :) Why do you think the STL is
like it is?
I've never heard a good reason why one shouldn't do a "using namespace
std;" at the beginning of every compilation unit. Maybe there're some
special cases where it might cause problems but usually not using that
is rather nonsensical, imho. The std:: is just clutter and that's
usually bad in a program.

Jeff Schwab

9/29/2008 2:27:00 AM

0

Mark Casternoff wrote:
> 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.

#1 for the case you've shown here, but #2 for functions, to give Koenig
lookup a chance. One of Scott Meyer's Effective {C++,STL} books has an
item on this. For longish implementation files, I'll sometimes put a
bunch of

using some_namespace::some_type;

near the top of the file. There's nothing wrong with using-declarations
("using std::cout;"), but using-directives ("using namespace whatever;")
can lead to weird problems (like potential name clashes whenever a new
name is added to the used namespace), and using-directives at global
scope in header files are just evil.

Rolf Magnus

9/29/2008 3:35:00 AM

0

Stefan Ram wrote:

> Mark Casternoff <mac@foobarnet.org> writes:
>>1) using std::cout;
>> cout << "This is a test";
>>2) std::cout << "This is a test";
>
> I believe the majority of programmers is using style 1.
>
> I prefer style 2, precisely, I prefer:
>
> ::std::cout << "alpha";
>
> Reasons:
>
> This code segment has a context-independent meaning
> to the maximum extend possible by such a segment:
>
> It can be copied from one source file to another
> without the need to copy a using declaration, too.

Well, you need to copy the #includes too.

> It can even be copied into
>
> namespace example { namespace std {} void example(){ ... }}
>
> and still retain its meaning.

I've never seen that anyone added his own namespace std somewhere. It would
be quite odd, so I don't see why I should attempt to protect against such a
case.

> ISO/IEC 14882:2003(E) is using »::std« once,
> »static ::std::locale::id« in 22.1.1.1.2.p1.

Once isn't really that often. How often does it not use that?

A disadvantage of explicitly qualifying with ::std or even with std is that
it makes it hard to create your own cout and replace all uses of the
standard cout with this one. If you have a

using std::cout;

cout << "Hello world\n";

you can simply replace the using declaration and you're done instead of
changing every single occurance of cout in your code.
And yes, I actually had a case where I wanted to exchange std::cout with my
own one. It was a microcontroller device with quite limited resources, so I
wanted to have something that behaves similar to cout, but provides only a
limited subset of the functionality to save resources.

ytrembla

9/29/2008 2:27:00 PM

0

In article <gbonpf$2ve$1@cb.generation-online.de>,
Hendrik Schober <spamtrap@gmx.de> wrote:
>Mark Casternoff wrote:
> OTOH, I have used #2 for about a decade now and worked on projects
> where it was required that /all/ identifiers have to be within some
> namespaces and that /all/ identifiers are to be addressed with their
> fully qualified name. So I /know/ that it isn't hard to read code
> which fully qualifies all identifiers after a short while of looking
> at such code (that's a "short" as in "weeks" or "months"). And this
> isn't only my personal POV. Most of the time I worked under the rule
> that using declarations (and even using directives!) where allowed
> within any local scopes not bigger than a function, but this was
> rarely ever used by anyone (with "rarely" meaning "far less than 1%
> of the project's code"). I suppose that was because, after a short
> while, people who really tried to work that way liked code better
> that used fully qualified identifiers. (I abhor code that uses a
> naked 'list' beside a naked 'cout', as I have no idea whether that
> is 'std::list' or some other identifier.)
>
> What I've learned, though, is to avoid creating namespaces which are
> long and hard to type right even after weeks ('StringUtility') of
> usage. :)

So essentially, the virtual ban on "using" coupled with the compulsory
namespace for everything leads to the creation of crytic namespace
identifiers?

<Ridiculous example>
Instead of the self explanatory "StringUtility", the
namespace becomes "su" and the call to su::strip(std::string const &)
which was meant to strip a string from trailing whitespaces
accidentally resolve to su::strip(std::string const &) from the su
namespace that a different developper created as a short for SuperUser
namespace, attempting to strip user rights from the passed string?
</Ridiculous example>

Personally, I try to place most things in namespaces. I very very
rarely use "using std;" because I find it far too broad and remove
clarity to the code. "list" for example is a very common word that
only has meaning with a context. std::list is clear. But the ban on
using directive of more than function scope: No thanks!

Yannick

ytrembla

9/29/2008 2:38:00 PM

0

In article <6ka9p5F6fbcoU1@mid.dfncis.de>,
Matthias Buelow <mkb@incubus.de> wrote:
>Mark Casternoff wrote:
>
>> I've seen both methods in code, but I'm seeing #2 a lot more frequently.
>
>It's because many C++ programmers prefer long-winded bureaucracy over
>conciseness or even (shock!) simplicity. :) Why do you think the STL is
>like it is?
>I've never heard a good reason why one shouldn't do a "using namespace
>std;" at the beginning of every compilation unit. Maybe there're some
>special cases where it might cause problems but usually not using that
>is rather nonsensical, imho. The std:: is just clutter and that's
>usually bad in a program.

The std:: namespace contains an awful lot of identifiers that use very
simple common words.

If you remove std:: namespace an put everything global, the following
becomes very undesirable since you would have trouble figuring out
which "map"

namespace DoraTheExplorer
{
class map
{
//
};

}
//////////////////
#include "Dora.h"
#include <map>

using namespace std; // or remove std:: altogether
using namespace DoraTheExplorer;

int main()
{
map theMap; // should this compile or error
// due to missing template arguments?
}


Hendrik Schober

9/29/2008 3:01:00 PM

0

Yannick Tremblay wrote:
> In article <gbonpf$2ve$1@cb.generation-online.de>,
> Hendrik Schober <spamtrap@gmx.de> wrote:
>> Mark Casternoff wrote:
>> OTOH, I have used #2 for about a decade now and worked on projects
>> where it was required that /all/ identifiers have to be within some
>> namespaces and that /all/ identifiers are to be addressed with their
>> fully qualified name. So I /know/ that it isn't hard to read code
>> which fully qualifies all identifiers after a short while of looking
>> at such code (that's a "short" as in "weeks" or "months"). And this
>> isn't only my personal POV. Most of the time I worked under the rule
>> that using declarations (and even using directives!) where allowed
>> within any local scopes not bigger than a function, but this was
>> rarely ever used by anyone (with "rarely" meaning "far less than 1%
>> of the project's code"). I suppose that was because, after a short
>> while, people who really tried to work that way liked code better
>> that used fully qualified identifiers. (I abhor code that uses a
>> naked 'list' beside a naked 'cout', as I have no idea whether that
>> is 'std::list' or some other identifier.)
>>
>> What I've learned, though, is to avoid creating namespaces which are
>> long and hard to type right even after weeks ('StringUtility') of
>> usage. :)
>
> So essentially, the virtual ban on "using" coupled with the compulsory
> namespace for everything leads to the creation of crytic namespace
> identifiers?
> [Ridiculous example deleted]

No. The next project introduced its string utilities
in a namespace 'Strings'.

> Yannick

Schobi

Matthias Buelow

9/29/2008 3:04:00 PM

0

Yannick Tremblay wrote:

> using namespace std; // or remove std:: altogether
> using namespace DoraTheExplorer;

....^ here

> int main()
> {
> map theMap; // should this compile or error
> // due to missing template arguments?

It should wail about symbol collision...^

Dunno if it does (too lazy^Wbusy to check now), b0rk3d as C++ is, it
probably doesn't.