|
|
|
|
|
|
by CyberDildonics
999 days ago
|
|
|
First, someone who modifies a header you include will now potentially break your code simply via a name collision. That would mean that they are writing their own global functions that collide with the standard library which is a pretty big mistake itself. Part of knowing the standard library is knowing not to make some function called end() in the global namespace. This really isn't a big deal. It's one of those group think ideas that permeates and lots of these jihads in programming have been totally wrong. This one I think is just blown out of proportion. There is a lot of simplicity in not having huge long lines for every type. Part of this can be done with auto, part of it can be done with aliasing, but an isolated namespace declaration isn't the end of the world. |
|
|
For end(), sure. But I listed a bunch more names that are way more likely to collide though... remove(), erase(), move(), search(), apply(), hash, format() are way more likely to collide. The fact that you have to pick the most implausible names to make your argument should be enough evidence that it's a strawman.
> That would mean that they are writing their own global functions that collide with the standard library which is a pretty big mistake itself.
No. It just means you're in the same namespace, or a sub-namespace of theirs.
You're also ignoring ADL effects and silent overload resolution changes, which I mentioned already.
> It's one of those group think ideas that permeates and lots of these jihads in programming have been totally wrong.
You've made factual mistakes in a bunch of your arguments -- most recently your misconception that such collisions only happen with the global namespace. Calling this "group think" and "totally wrong" when your arguments rest on incorrect assumptions is not really warranted.
> There is a lot of simplicity in not having huge long lines for every type.
You're arguing as if we don't understand that... despite the fact that I evidently did, as I explained earlier how you could achieve that simplicity by doing "using std::foo;" instead of "using namespace std;", while avoiding the vast majority of the downsides I'm pointing out.
OTOH, what you don't seem to be considering (and which I've been trying to point out) is the various types of friction you're introducing for your coworkers and future maintainers.
> an isolated namespace declaration isn't the end of the world.
"Not end of the world" is a... low bar. Just because a practice isn't the end of the world, that doesn't mean avoiding it isn't a better idea. I've pointed out several reasons why: unintended ADL lookups, ridiculous error message noise, silent misbehavior, name collisions, difficulty of changing dependent code without breakages, etc. And I've pointed out how you can still achieve your goal while mitigating these considerably.
I don't have anything else to add.