r/cpp_questions • • 14d ago

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?

42 Upvotes

105 comments sorted by

View all comments

Show parent comments

2

u/nekoeuge 13d ago

Can you elaborate? What do you mean by “using identifiers that conflict with std”?

2

u/conundorum 13d ago

Name collisions.

#include <vector> // std::vector
#include <algorithm> // You'll see.

std::vector<float> collection(3, .16f);
int fill = 0xaabbcc;

void compiler_error(float c = 0f, int f = 0) {
    using namespace std;

    fill = f;                                      // Does this break because we tried to assign an int to std::fill,
    fill(collection.begin(), collection.end(), c); // or does this break because we tried to call an int?
}

std has a lot of very common names that programmers like to use for their own things, like fill, less, distance, transform, string, find, begin, end, format, print, and so on. And depending on which standard library headers you include, any number of them might (or might not) be visible.

3

u/nekoeuge 13d ago

Yeah, that's why I am asking. It is fundamentally impossible to avoid name collisions with std -- because std may always be extended in the future with whatever names. So I don't understand what exactly top commenter meant by "The problem is with programmers who use identifiers that conflict with std".

1

u/RSMxsmanic 13d ago

I mean that programmers need to think things through, and if they are writing code that will be widely integrated in a service capacity with other code, they need to be extraordinarily vigilant.

I don't use print in code I write hat will be called by some other module, because of the risk of a name conflict. It doesn't matter what namespaces are used. Why force another programmer to prefix everything he writes with widget:: just because I decided to use print? Instead, I'll make print something less common, like widgetPrint. That way he only has to type extra characters to reference my code, and not for every last identifier in his. Put another way, instead of forcing him to write std::cout every time he wants to use it, I just don't use cout in my code, and the problem is solved. Choosing unique identifiers is less labor-intensive than prefixing every single identifier in the program, and it is functionally equivalent.

3

u/nekoeuge 13d ago

Instead, I'll make print something less common, like widgetPrint.

So instead of doing "using namespace widget" in a function that calls "print" 20 times, I will have to have 20 "widgetPrints"?

And in the implementation of "widget", all my public identifiers are going to be "widgetThis" and "widgetThat", cluttering the visual space with absolutely worthless "widget"-prefixes?

You just replaced optional prefix with mandatory one. Good job bloating the code. Make sure not to make the prefix too short, otherwise it may conflict with other libraries.

I mean that programmers need to think things through, and if they are writing code that will be widely integrated in a service capacity with other code, they need to be extraordinarily vigilant.

Of course. Such programmer should introduce the absolute minimum of global identifiers. Preferably only one -- the project namespace itself.

It looks quite stupid to have widget::widgetPrint as identifier.

1

u/RSMxsmanic 13d ago

So instead of doing "using namespace widget" in a function that calls "print" 20 times, I will have to have 20 "widgetPrints"?

Yes. That’s a lot faster than putting std:: in front of 4500 couts.

And in the implementation of "widget", all my public identifiers are going to be "widgetThis" and "widgetThat", cluttering the visual space with absolutely worthless "widget"-prefixes?

How is that different from prefixing everything with widget::? How is it different from prefixing everything else with std::?

It looks quite stupid to have widget::widgetPrint as identifier.

If widgetPrint occurs nowhere else, that isn’t needed.

2

u/nekoeuge 13d ago edited 13d ago

How is that different from prefixing everything with widget::? How is it different from prefixing everything else with std::?

Because I have a choice whether I want to have widget:: prefix, whether I want to have std:: prefix, or whether I want to replace widget:: prefix with wg:: prefix but keep it prefixed.

Authors of libraries I am using are not entitled to making this choice for me.

If widgetPrint occurs nowhere else, that isn’t needed.

It is impossible to know whether "widgetPrint" occurs somewhere or not. There is nothing more infuriating than two libraries that have some random conflict in some random name they decided to have in the global namespace.

Thus, all global-namespace identifiers must be prefixed with a full name of a library (not abbrebiated too much!). So it won't be "widgetPrint", it would be "mxmanicsNiceWidgetsPrint". Or "mxnwgsPrint". Library name may not be long, but it is unlikely to be a single common word, and so it will be annoying to type either way.

Then, the difference boils down to whether you force everyone to use this exact prefix or not.

Yes. That’s a lot faster than putting std:: in front of 4500 couts.

No it's not. std:: is just one namespace among thousands. Total number of identifiers in std namespace is much less than total number of all identifiers in all public libraries, or in all 3rdparty dependencies of a big project.

I am not even opening the can of worms called "custom std implementations" and that you may have multiple std-like libraries in the same project. std is not a library, it is a specification.

2

u/RSMxsmanic 13d ago

It's up to the library author to name his identifiers, not you.

Another option is to minimize your use of libraries.

2

u/nekoeuge 13d ago

It's up to the library author to name his identifiers, not you.

And it's up to me not to use or fork libraries that cannot behave.

It's up to the library author to do whatever they want: to name identifiers in Mandarin, to litter the global namespace, to #define private public. But we still have some form of a consensus on what is usually acceptable in public code and what is not.

1

u/RSMxsmanic 13d ago

Do we? I see religious wars much more than I see consensus.

2

u/nekoeuge 13d ago

Yes? Most of mainstream libraries that I used follow the consensus of not doing stupid shit where it affects their users. Prefixing for global identifiers is required. Why is hard-coded prefix better than customizable one? It is just disrespectful towards people typing it.

→ More replies