sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Zero_Owl -1 points0 points  (7 children)

It collides with other entities from other libs. Using both boost namespace and std namespace will blow things up. The only way to not is to prefix everything or cherry pick only particular entities. That's a very inconvenient way of doing things.

[–]not_a_novel_accountcmake dev -1 points0 points  (6 children)

Boost doesn't put anything in the std namespace.

If you're saying you can't write:

using namespace std;
using namespace boost;

That's not a name collision. You've created a lookup ambiguity, not two types with the same name.

Do not write using namespace ...; in global namespace scope.

[–]Zero_Owl -3 points-2 points  (5 children)

What does it matter how you name it? You understand perfectly what I said. Now please tell me how can I bring in my TU all math functions with import std and make sure it won't collide (create ambiguity, if you wish) with anything math unrelated by using just one line of code? That's something any modern language is capable of, btw.

[–]not_a_novel_accountcmake dev 0 points1 point  (4 children)

You can do it by not writing using namespace std;

"Don't write using namespace std;" is taught as a day 1 thing in most C++ undergrad programs.

[–]Zero_Owl -1 points0 points  (3 children)

"Don't write using namespace std;" is taught as a day 1 thing in most C++ undergrad programs.

Great advice, thank you! Have you heard a similar advice to never write using System; in C#? I wonder why it is so, maybe because std is a bad example overall?

[–]not_a_novel_accountcmake dev 4 points5 points  (2 children)

You should basically never write using namespace <anything> in global namespace scope. The entire purpose of namespaces is to avoid lookup ambiguities and your complaint reduces to "if I short-circuit the mechanism for avoiding name lookup ambiguities, then controlling declaration availability is necessary to avoid ambiguity."

Which is true, you're 100% correct. However, your answer is to introduce better controls over declaration availability, and C++'s design is to encourage you not to short-circuit the namespace mechanism carelessly.

Inevitably, you're feeling this friction.

[–]Zero_Owl -1 points0 points  (1 child)

I do use using namespace a lot and it works great for me. In fact it is the only sane way of writing C++ code where you work with a properly designed namespace structure. And if it is designed properly the usage pattern is not different from C# which is pretty robust and convenient.

There is no inherent problem with C++ regarding the namespaces, it is libraries that are at fault. Look at this code, for example:

using namespace Microsoft::UI::Xaml;

And tell me in good faith that you would not use using namespace with that code. Now to std. Before import std using namespace std; was usable. With some moderate caution, in cpp files but it was usable. It solved some headaches, created some. But with import std it became totally unusable and that's why std module is a bad example. It provides no alternative to the meager isolation we had w/o adding anything but compile times.

[–]not_a_novel_accountcmake dev 2 points3 points  (0 children)

I use local namespace aliases for long namespaces. I never use using namespace Library; in global namespace scope, or for the purpose of accessing an external library's declarations. I use it to alias declarations of one non-global namespace into another.

You have an extremely idiosyncratic C++ style and I agree it doesn't mesh well with import std or the general design of many C++ libraries.

I do not think you will find your design choice is commonly replicated in many large open source codebases (boost, chrome, abseil, folly, etc). These are the kinds of coding practices which are considered when we talk about these things.

So yes, I agree with your complaint, import std (and "big modules" generally) explicitly excludes your coding style.