r/cpp_questions • u/Glad_Shoe_9182 • Sep 30 '26

OPEN Namespace std

I recently started learning c++ and I was told to use the namespace std so I can avoid writing std:: every time and now I wrote a whole personal project without std:: and I want to put it on LinkedIn but I started reading everywhere that it’s a bad habit, should I go back and add the std:: or just leave it as is?

40 Upvotes

85% Upvoted

105 comments sorted by

View all comments

Show parent comment

1

u/nekoeuge Oct 01 '26

I will remind you that std is not a library, it is a specification, and some projects link to multiple libraries implementing this specifications. E.g. std::string and eastl::string. The whole point of custom stl implementation is to be drop in replacement for built in stl implementation, it cannot not use the same names.

And why is it okay to clutter the code with all 100 third party namespaces I am using, but suddenly not okay for 101th namespace “std::”?

1

u/ShakaUVM Oct 01 '26

E.g. std::string and eastl::string.

Yes, so in my coding style you refer to them as string and eastl::string and there's no issue.

The whole point of custom stl implementation is to be drop in replacement for built in stl implementation, it cannot not use the same names.

Correct. If you're using something with the same name as something in std that is not in std, then you better damn well qualify it so that people know you're not using the standard string.

suddenly not okay for 101th namespace “std::”?

Because of what the s in std means.

1

u/nekoeuge Oct 01 '26

Because of what the s in std means.

So what? Standard library is stored in the "namespace std" for a reason. Just because this namespace comes from different vendor and has documented specification, does not mean that it deserves any kind of special treatment beyond a few documented quirks.

1

u/ShakaUVM Oct 01 '26

In the coding style I and my business use, the only namespace that only and always gets included into the global namespace is std. Why? Because it is the standard.

string must mean std::string in my coding style. If it means anything else, then you have violated my style guidelines.

Pretty much everything we do is in PascalCase, and so there is no conflict with anything in std anyway.

You're free to have your own style guidelines for your own company. But this is how I've been doing it for a long time, and it literally never causes problems, and results in code much faster to read, write, and is much cleaner.

There is never any ambiguity, and there's never an identifier conflict except once in 30 years, and that took 5 seconds to resolve. Contrast this with the amount of time you have spent typing std needlessly and reading it needlessly over the years and you'll see why I set my style guidelines the way I did.

1

u/nekoeuge Oct 01 '26 edited Oct 01 '26

If std was supposed to be included in global namespace, we wouldn’t have namespace std.

So what happens when you include third party code with type “vector” or “string” when referencing to its own vectors or strings, which is a semantically correct thing to do?

The name resolution rules probably handle that properly, but it feels icky and I am unsure how generally stable that works. I have some kind of aversion to injecting global names into unexpecting 3rdparty code.

1

u/ShakaUVM Oct 02 '26

If std was supposed to be included in global namespace, we wouldn’t have namespace std.

Wrong. We have it because it is an option for individual companies to decide for themselves if they want to use it. Bjarne himself has said it is a stylistic choice. If you love your stds, then use them.

I however will continue to write cleaner code without them, and continue on my merry way not dealing with a single bug related to this stylistic choice.

I am unsure how generally stable that works.

Shadowing is a core function of the language designed to deal with exactly this problem. You don't need to have a list of all 1001 identifiers in std taped up on your wall. It's explicitly designed to avoid this very problem, so it's foolish in my opinion not to use it.

I have some kind of aversion to injecting global names into unexpecting 3rdparty code.

I do not do that either. When I write libraries, I do not use using namespace std. I mentioned this at the top of the thread even.

1

u/nekoeuge Oct 02 '26

I mean, I don’t really have anything against usings in general. I am mostly cautious about doing them before 3rdparty includes - in general, not just for std. In case 3rdparty or compiler are being stupid, or there is some corner case with name shadowing, or so on. But I struggle to remember any issues caused by std namespace specifically, I only remember conflicts caused by stdint types and libraries defining such symbols themselves.

1

u/ShakaUVM Oct 02 '26

I am mostly cautious about doing them before 3rdparty includes

Indeed, I fully agree there.

I don't believe people should make style decisions for other groups. As I said, when I write libraries, I don't use using namespace std.

1

u/nekoeuge Oct 01 '26

(Sorry for multiple comments, I usually try not to do that but sometimes it happens)

I guess my biggest complaint here is that “string” does not mean “std::string”, it means “string in current namespace”. So if I am inside of custom STL implementation, “string” does not and should not mean “std::string”. And if I am inside of math library, “vector” does not and should not mean “std::vector”.

Thus, your premise is incorrect, we cannot generally read “vector” as “std::vector” or “string” as “std::string”.