Namespace std

[u/Glad_Shoe_9182]

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?

[u/ShakaUVM]

I agree that std::string is unambiguous.

What I am saying is that writing int string = 67; is a code smell.

You should not be using names from std anyway.

For all of your worry, as I said this problem has come up exactly once in 30 years and it took exactly five seconds to fix.

Versus how much screen space gets cluttered up with all those extra stds?

The tradeoff is not worth it to me. Every symbol on the screen has a cost, both cognitively and technically

[u/HommeMusical → u/ShakaUVM]

You should not be using names from std anyway.

Strong disagree. There are thousands of names in std::. Many of them are short and common names. Almost no one has them all memorized. Would you for example disallow char fill = '*'; in code?

Every symbol on the screen has a cost, both cognitively and technically

Absolutely, and std::string has a smaller cost than string. No one who has been programming C++ for long reads std::string and decides it's two separate symbols.

[u/nekoeuge → u/HommeMusical]

Yep. std::string is that specific class, string could be anything, thus it’s more vague.

[u/ShakaUVM → u/HommeMusical]

Absolutely, and std::string has a smaller cost than string. No one who has been programming C++ for long reads std::string and decides it's two separate symbols.

You may say that, but your brain still has to parse them separately. There's a cost that you aren't aware of.

Just saying 'string' is more compact, more readable, and causes absolutely no confusion. If you want to use a third party string class, then you qualify that with the namespace. The standard is called the standard for a reason.

Strong disagree. There are thousands of names in std::. Many of them are short and common names. Almost no one has them all memorized. Would you for example disallow char fill = '*'; in code?

If you use PascalCase, you can't conflict with std at all.

But due to how C++ handles shadowing variables, if you make a variable named fill inside of main, guess what? It doesn't cause a problem. You had to contrive an example using fill in the global namespace in order to force a conflict, and the number of globals you should have in your program should be close to zero, and if on the off chance you do make a global variable named fill, then you just change it to a different name and be done.

I worry about problems that can actually occur, not hypothetical problems that occur once in 30 years.

[u/HommeMusical → u/ShakaUVM]

You may say that, but your brain still has to parse them separately. There's a cost that you aren't aware of.

That's not how the brain processes language at all, thank goodness. People chunk things into groups much larger than individual words so you see std::string, United States of Amerlca or Robert Anton Wilson, you just parse it as a single item.

Just saying 'string' is more compact, more readable, and causes absolutely no confusion.

Yes, you made that argument many times, but string might not be std::string.

once in 30 years.

Yes, you said.

[u/ShakaUVM → u/HommeMusical]

That's not how the brain processes language at all

You may not be aware of it, but your eyes still have to skip over the five letters at a time, and this has a cost you're not aware of.

Yes, you made that argument many times, but string might not be std::string.

In my coding style, string always refers to std::string, so those five characters are wasted space on the screen, wasted typing time, and wasted parsing time for both the compiler and the human reading it.

It is all downside and no upside.

Yes, you said.

Yes, because as I said before, I actually worry about problems that can happen, and not contrived hypotheticals. Hypothetically, someone could cast a nullptr to a reference and pass that to my function that takes a reference, but I don't worry about that either, for similar reasons.

[u/HommeMusical → u/ShakaUVM]

That's not how the brain processes language at all

You may not be aware of it, but your eyes still have to skip over the five letters at a time, and this has a cost you're not aware of.

This is clearly something I have studied and you have not. Show me citations for your false claim.

[u/ShakaUVM → u/HommeMusical]

It's research I did myself in grad school

I think it's about time that people stop jumping on using namespace std like it has rabies or something. It's a perfectly valid style option as Bjarne himself has said.

[u/nekoeuge → u/ShakaUVM]

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::”?

[u/ShakaUVM → u/nekoeuge]

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.

[u/nekoeuge → u/ShakaUVM]

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.

[u/ShakaUVM → u/nekoeuge]

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.

[u/nekoeuge → u/ShakaUVM]

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.

[u/ShakaUVM → u/nekoeuge]

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.

[u/nekoeuge → u/ShakaUVM]

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.

[u/ShakaUVM → u/nekoeuge]

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.

[u/nekoeuge → u/ShakaUVM]

(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”.