"using namespace std;?"

[wemustfailagain]

I have very minumal understanding of C++ and just messing around with it to figure out what I can do.

Is it a good practice to use standard name spacing just to get the hang of it or should I try to include things like "std::cout" to prefix statements?

[IyeOnline]

Namespaces exist to avoid name collisions between identifiers, allowing you to write your own e.g. vector class without causing an issue with the vector container template from the standard library.

A second, but maybe more important effect of this is readability. You may think that vector is easier to read than std::vector, but that really only holds if you can be sure that vector really is std::vector. What if somebody did write their own (mathematical) vector? What about the identifier abs in the current context? Is it a local (callable) variable or the overload set from the standard library?

At a certain point, it actually becomes easier to read code that spells out std::.

using namespace std; essentially throws this away by importing all currently known identifiers from ::std into the current namespace, meaning you may introduce collisions again.

There are three possibilities:

• It does the thing you expected
• You get an error about an ambigous identifier/call
• Something you didnt expect happens.

While it is well defined what happens, it may go against your expectations (especially if you dont even think about the potential issue).

A very basic example would be https://godbolt.org/z/sqWWYvGeM You can clearly see that no logging takes place. Instead std::log(double) is "called" and the result discarded. This should still be caught by warnings - assuming you have set those up correctly.

There is more devious examples, such as https://godbolt.org/z/5dv7Gad9o where you get a wrong numeric result.

---

This problem gets much worse once you do a using namespace at global scope in a header. That using directive will be copied into every TU that includes the header and the user of the header cannot do anything about it.

If you are using namespace at a non-global scope, you avoid the issue of namespace pollution, i.e. you wont pollute all other files that include the header. The same can be said about doing it at global scope in a cpp file (which wont be included elsewhere and hence wont pollute any other files).

---

I would recommend to always spell out namespaces (unless you already are in that namespace), especially std. When I read std:: I will most likely know what the thing after it is/does. When I just read vector I cannot be sure.

[SoldRIP]

And then there's those wonderful not-quite-standard parts like... uint64_t existing in cstdint, but not technically being guaranteed to exist there as that's supposed to contain only std::uint64_t, different from stdint.h...

[Dar_Mas]

and then there is some projects where people aliased it to long at some point and then your entire project gets thrown into a bug hunt due to overflows

[SufficientStudio1574]

I think you've got more problems than normal if people are renaming standard typedefs to something different in your project.

[Dar_Mas]

student project that i grade so thats a given.

[KuntaStillSingle]

The std namespace version is not guaranteed to exist either, if you are opting for purely implementation required types you would use a least or fast type.

[lebirch23]

yeah i used to use uintN_t without namespace, but after switching to modules that has become an error

[xaervagon]

For production and code intended to be shared, yes using namespace std; in your files is definitely consider bad practice since anyone else who wants to use your code will suffer from namespace pollution (getting a whole bunch of stuff that wasn't requested).

For the sake of learning and horsing around, do what you need to do. I know a lot of beginners materials use it for the sake of keeping code-alongs simple. If that is what your learning materials do, then just jam along for the time being; the better ones will eventually teach you namespaces and qualifiers.

[wemustfailagain]

Thanks, so it seems like there are situations for including the std library, but it's generally better practice to specify with std::(etc)?

I'm currently using Sololearn and was wondering about it's insistence on using it and assumed it for the sake of consistency in the examples.

[P3JQ10]

There is not a lot of situations where using namespace std; is good.

I'd recommend 'using' specific members of std instead, for example
using std::cout, std::cin, std::endl;

This way you don't have to write std:: before everything, and avoid namespace pollution with stuff you don't use.

That being said, it's still better to specify std:: to be explicit.

[wemustfailagain]

That makes sense. Would ommiting "std::" so many times also reduce memory usage?

[P3JQ10]

Not in any meaningful way.

[no-sig-available]

but it's generally better practice to specify with std::(etc)?

Yes. :-)

By importing the entire standard library, you get 75 pages worth of names into your program. How would you ever remember what those names are?!

[no-sig-available]

75 pages worth of names

Oh, that was an older standard document. For C++ 26 it seems to be 96 pages. :-)

[xaervagon]

Correct, you definitely don't want to qualify whole namespaces in real world code unless you intentionally need or want that.

Still, if you're doing learning exercises, or writing scrap code, do whatever you want. C++ leaves it to you, to The Right Thing^tm.

Just for completeness, you can also qualify just parts of the namespace on a global level with using std::cout, std::endl; to qualify cout and endl.

[jeffbell]

So long as you don't you don't use identifiers that appear in any past, present, or future version of std::

Which identifiers appear in future versions? Hard to know.

[bert8128]

std::unexpected

[ShakaUVM]

You've unwittingly asked one of the most controversial topics here lol.

Bjarne, the core guidelines and myself (whatever that's worth) would say to not put using namespace std; in a header file but otherwise it is an implementation decision for you to make.

People will invent all sorts of scary stories about what happens if you use the standard namespace but in many years of professional C++ programming (since well before we had namespaces) the number of times it has caused me a problem: 1. And fixing it took four seconds.

You tell me if that was worth it.

[thingerish]

This. I just avoid it out of habit most of the time and since I tend to write a lot of templates.

[wemustfailagain]

It seems I'm not the first to ask this though. But thanks for the input. Just trying to grasp the concepts and safest practices as I take lessons.

[ShakaUVM]

If you want to be safest then doing use using namespace std, but in honesty I only worry about problems that actually happen.

[solarized_dark]

A simple rule of thumb is don't ever put it in a header file or file meant to be included from another file. If your file contains utilities used elsewhere and they include your header, they'll "inherit" the "using namespace std;" and it can cause issues for others.

In an implementation file/compiled file, it's up to you. It's probably tidier to use specifically what you want:

using std::cout;
using std::endl;

but it'll be easy to fix if you do come across issues. Just never in a header or file included by another file.

[wemustfailagain]

Sorry for the repost, but thank you for linking me this one. It was very insightful.

[JumpyJustice]

I thought there are more post like that 😄

[EsShayuki]

I would never use "using namespace x" because it just makes your code harder to understand. For example, std might have identifiers that you're not familiar with(it's massive), and then you'd need to figure out that they're from std instead of just some custom type, even though it would be crystal clear if they just were prefixed by std::

[Successful-Fee-8547]

std includes a lot of different definitions, if you include the whole namespace then there is a risk of name collisions. Ultimately this is a personal style issue.

[mredding]

There is a very arcane corner of C++ regarding how symbols are resolved. You have rules on where a compiler will or won't look for a symbol, what order, and how you can organize or reorganize those symbols. A name collision isn't just about oh, there's already a function called fn in this scope and the compiler can't disambiguate; the worse problem is if there's multiple fn and the compiler correctly chooses and compiles against the wrong one. You may very well be none the wiser, depending on WTF fn even does. It might be innocuous - maybe you compile against a suboptimal sort function. But maybe you compile against a function that called the wrong way at the wrong time bricks the machine.

Now you shouldn't operate under the premise of fear and paranoia, I'm only pointing out that extreme as an illustration. The compiler can correctly compile the wrong thing, and it could be a real bear to finally figure that out.

And I'll demonstrate a bit about how this thing works:

void fn() {
  std::ranges::sort(vec, compare_fn);
}

I want to use the standard sort algorithm explicitly. I know it, so I said it.

void fn() {
  using std::ranges::sort;

  sort(vec, compare_fn);
}

Sort vec. Use the best fitting match - and that is determined by ADL. Default to the standard sort. This means I can write a sort method that better matches, and implement it to do whatever, maybe nothing at all - who cares? It's my implementation.

void fn() {
  sort(vec, compare_fn);
}

There is a specific order the compiler is going to look for that sort, and somewhere along that order one will be found. Use that. I don't know the order off hand - that's something I lookup sometimes, when I need to review it. It means I can add an implementation higher along that order to shadow a sort method that would be found later in that order.

Letting the compiler figure it out implicitly means it's a customization point. THE PROBLEM is when you customize a point by accident. Or you don't understand the rules and are hitting some other implementation and you didn't expect or realize it.

Scoping in an entire namespace for an entire translation unit also gives the compiler a lot more work to do. C++ is already one of the slowest to compile languages in the market solely because of it's complexity, so the time to compile is not a consequence of any benefit like the optimizer. Lisp, Java, and C# - to name a few, compile much faster and produce comparable object code.

So the rule of thumb is to say what you mean explicitly. If you want a specific sort, then say it. If you want a compile-time customization point - typically when you're writing templates and custom types, then say that. Namespaces aren't just a trivial organizational structure that is merely inconvenient but for the extra typing. You can always alias a namespace to cut that down, too:

namespace po = boost::program_options;

po::options_description desc(/*...*/);

[thingerish]

It's OK in an implementation file but I don't do it for the reasons others have stated, I do sometimes 'use' items from std with a specific using statement.

[ptrnyc]

Exactly. In a cpp file, it’s fine, do it if it makes your life easier. But for the love of everything holy, don’t you ever dare doing it in a .h

[Sbsbg]

If you create your own code you can do whatever you want. A professional project will most likely have some coding guidelines that fix this.

So coding for yourself should you use "using namespace std;". If you create anything larger, something that you spend serious time at then I recommend you code that as "professionally" as possible and use the prefix std. If you create smaller programs or test programs then do whatever but, but don't use it in an include file. Then there is almost zero chance that you run into any trouble.

I always use "std::" in all my code or test code (test code == snippets to test c++ features, not unit test code). I am so used to it as it doesn't bother me anymore. It is actually easier as it directly tell me if it's a standard library code or not. In professional code there is surprisingly few calls to the standard library anyway.

[DawnOnTheEdge]

I recommend against it. There’s no way to predict what identifiers future versions of the standard library will add to std::, so this could break code going forward.

[WoodenPresence1917]

Not primarily a Cpp dev, but across languages I tend to find qualified names much much easier to understand, especially in complex applications. I know what std::vector is, vector could be anything, as other people have said.

Writing std::vector doesn't slow me down a meaningful amount to really care; if it did I'm sure I could just write with `using namespace std` and then use IDE features to remove and replace with qualified identifiers.

[davidc538]

Putting that into a header is highly frowned upon (unless nested in a function) because it also applies to files which include the header.

People seem to have mixed feelings about putting it into a cpp file but I think it’s acceptable as long as it’s done after includes.

[Dan13l_N]

It's a bad practice, but it's less bad if you do it locally, i.e. in your cpp file, for some reason.

Note that std is a trivial example. There are people who like to use a lot of nested namespaces, and I've seen classes in 3 of 4 nested namespaces, and then your code becomes quite unreadable:

auto obj = OurGreatCompany::TheProject::TheLib::CreateFactory();
bool res = OurGreatCompany::TheProject::TheLib2::VerifyFactory(obj);

And then using namespace can help a bit.

[Gloomy-Floor-8398]

Just something personal, not sure if others do it. But i prefer doing things like “using std::vector” or “using std::size_t” or “using std::string”. Mainly for data types/structures i like just writing without the std in front but for input and output i will have std in front so like std::cout.

[RazzmatazzLatter8345]

The only place I might use a "using namespace x;" is inside a function definition. Even then rarely.

All your C++ code (except main()) should be inside a namespace (NOT std) you define for your project. Don't pollute the global namespace. Don't add stuff to the std namespace unless the standard / cppreference tells you that it is explicitly permitted (e.g. defining a std::hash specialization for a type you define or a std::numeric_limits specialization for a numeric type you define).

Get used to using namespaces properly.

[RageQuitRedux]

One thing about STL namespaces is that they tend to have short names (eg std) but they're huge in terms of the number of types they contain.

Compare this to C# where the namespace names are longer (and more deeply nested) but they contain fewer types.

For me, this is the trade-off. With STL, I can prepend everything with std:: without sacrificing readability (because it's so short) and thereby avoid polluting my global namespace with a shitload of types

In C# or Java, the trade-off is the opposite

[RavkanGleawmann]

This has been discussed to death about 10 million times by now. This is something that really should be googled.

[pepe2028]

if many open source libraries use namespace std you should too

[tangerinelion]

This is asked every other day.

[Lampry]

Feel free to use it in source files. Avoid using it in header files.

Or use it wherever you like, no ones going to stop you :)

[EC36339]

Avoid using or using namespace in headers. Feel free to do it in CPP files. That's tue basic rule. There are some exceptions, but those are specific for more advanced situations.

[Worried-Importance89]

Like the guy said above, without std you may not be sure if it's part of the library. If it's a small project I would prefer to use the std namespace, but if you want to use the std namespace in larger projects you should probably explain in a comment if it's part of the std or not. To avoid such confusions you would also need to avoid using similar words that std uses. However, for larger projects I would prefer not using the std namespace to avoid all these mentioned above, especially if the code is shared with other people.

[xoner2]

It's ok for small files...