Morality of std:: prefix

[cppaddict]

Hi,

I'm curious about the pros and cons of using the std:: prefix versus
the "using namespace std;" directive.

Obviously the directive saves you some typing, but I seem to remember
reading somewhere that it is not good form. Maybe because it is not
immediatly apparent which objects are part of the standard libraries
and which are your own.

Does anyone have additional thoughts on the matter or know what the
expert consensus is, assuming there is one?

Thanks,
cpp

 

[Victor Bazarov]

I'm curious about the pros and cons of using the std:: prefix versus
the "using namespace std;" directive.
[..]
Does anyone have additional thoughts on the matter or know what the
expert consensus is, assuming there is one?

The consensus can be found (with some effort) on Gougle Groups. If
you really can't find it, perhaps reading some modern books on C++
written by experts might help. Even the FAQ has a couple of words
on coding standards (although none on 'using' versus 'std::') with
links to more online resources.

V

 

[Victor Bazarov]

I'm curious about the pros and cons of using the std:: prefix versus
the "using namespace std;" directive.
[..]
Does anyone have additional thoughts on the matter or know what the
expert consensus is, assuming there is one?

The consensus can be found (with some effort) on Gougle Groups. If
you really can't find it, perhaps reading some modern books on C++
written by experts might help. Even the FAQ has a couple of words
on coding standards (although none on 'using' versus 'std::') with
links to more online resources.

V

 

[Phlip]

I'm curious about the pros and cons of using the std:: prefix versus
the "using namespace std;" directive.
Pro.

Obviously the directive saves you some typing, but I seem to remember
reading somewhere that it is not good form. Maybe because it is not
immediatly apparent which objects are part of the standard libraries
and which are your own.

Why should the language have a namespace feature if you are just going to
throw it away?

 

[Dan Moos]

Why should the language have a namespace feature if you are just going to

throw it away?

Why should my car have a ciggarette lighter "feature" if I'm not gonna use
it

that's just me playing the devil's advocate by the way. I think "using"
using is probably not the way to go, although laziness more often than not
wins me over.

 

[Duane Hebert]

Why should my car have a ciggarette lighter "feature" if I'm not gonna use
it

that's just me playing the devil's advocate by the way. I think "using"
using is probably not the way to go, although laziness more often than not
wins me over.

Why should my car not have a cigarette lighter just because you're
not going to use it <g>

Please don't put "using namespace whatever" in a header
file that someone else may be including. This is nearly
as bad as MS's propensity for global macro names.
Note also that std:: is not the only possible namespace.

Aside from that, it's probably largely a matter of preference. My
preference is to use the namespace prefix.

 

[Gary Labowitz]

Why should my car have a ciggarette lighter "feature" if I'm not gonna use
it

It's not a cigarette lighter, it's a utility power source. Some people use
it to power a cigarette lighter, but others don't.

 

[Jeff Schwab]

I'm curious about the pros and cons of using the std:: prefix versus
the "using namespace std;" directive.

Obviously the directive saves you some typing, but I seem to remember
reading somewhere that it is not good form. Maybe because it is not
immediatly apparent which objects are part of the standard libraries
and which are your own.

Does anyone have additional thoughts on the matter or know what the
expert consensus is, assuming there is one?

The "expert consensus" is that using directives are bad. I think
there's a lot of misunderstanding about them, though, and while I don't
always use them, I think they are undervalued.

Using directives do not introduce anything into the current namespace.
They only make things in other namespaces available, if no local version
has been defined. This is very similar to the way that variable
declarations in an inner scope mask similar declarations in outer scopes.

A line like "using namespace defaults;" tells the compiler, "if I use a
function named foo, and there's a locally declared foo, use it, but if
there's no locally declared version, here's a good place to look for a
default." This and Koenig lookup can help make sure you always get the
best (most specialized) default versions of things. If there's ever a
conflict between Koenig and a using directive, the compiler will let you
know, and you just add a using declaration to remove the ambiguity.
This is similar to the way such a declaration can be provided in a
subclass to disambiguate use of an identifier declared in multiple base
classes. If you explicitly use std::some_function all the time, you'll
miss out on any local overloads of some_function.

#include <iostream>

namespace udts
{
struct Udt { };

void print( Udt ) { std::cout << "udts:rint\n"; }
}

namespace defaults
{
void foo ( ) { std::cout << "defaults::foo\n"; }
void bar ( ) { std::cout << "defaults::bar\n"; }

void print( udts::Udt ) { std::cout << "defaults:rint\n"; }
}

namespace local
{
void bar ( ) { std::cout << "local::bar\n"; }

void f ( )
{
using namespace defaults;

bar( ); // Local bar.
foo( ); // Defaults to defaults::foo.

using udts:rint;
// The using directive conflicts with Koenig, so the
// compiler will give an error about ambiguity if this
// declaration is not provided.

print( udts::Udt( ) ); } }


int main ( )
{
local::f ( );
}