[vlc-devel] [vlc-commits] Remove using namespace std; from C++ code

[Rémi Denis-Courmont]

Le lundi 22 juin 2015, 18:23:18 Hugo Beauzée-Luyssen a écrit :
> > Anything that involves defining atomic_int on C++ and not on C (or
> > vice-versa) is bound to failure. There are no warranties from the
> > compiler that the results will be compatible, and in fact, they typically
> > would not be. Either we have custom (identical) definitions all the time,
> > or we always use the compiler definitions. The latter ostensibly implies
> > compiler support for C11 *and* C++11 atomic types.
> 
> By "specifying ourselves [...]" I mostly meant "typedef std::atomic<int>
> atomic_int", which is the compiler definition.
> No custom types are introduced.

If the compiler has a definition, then you can use it, and the typedef is not 
needed (if even possible). If the compiler has no definitions, then the two 
sentences are absurd.

> >> rather than relying on
> >> std::atomic_int, which is a specialization std::atomic_base.
> >> 
> >> Doing so with a using namespace std; will cause 2 different types with
> >> the same name to appear in the global namespace, thus causing the build
> >> to fail.
> > 
> > Again, you are just moving the problem: now some out-of-tree C++ plugins
> > are most likely broken, instead of the VLC build. I do not believe that
> > we can require out-of-tree plugins to not use (or to use) the std
> > namespace.
> As long as you're putting the using statement after requiring
> vlc_atomic, things will be fine.
> It's not ideal, but it's not that bad.

*You* deal with support issues and the bad press then.

> >> I don't really have any other proposal to fix the builds, which are not
> >> involving rolling back to C++99, requiring GCC 5.x, or using atomic
> >> types for c++, and atomic functions for C.
> > 
> > In my *opinion*, last February was very early to introduce C(++)11 given
> > how recent support is in compilers. I do not *personally* care either
> > way: I was then fine with C99 plus anonymous unions plus Intel atomic
> > intrinsics. I am now fine with C11 with atomics and with VLAs (and
> > without threads).
> > 
> > But of course, some people will want to use GCC 4.9, probably 4.8 and
> > maybe
> > older. Those people should have been pissed with the change.
> 
> I'll emphasize that the original switch was to use C++11 *if available*,

...and generating invalid byte code in C++ plugins due to mixing with C99. I 
am pretty sure I mentioned already that mixing C++11 with C99 or C++98 with 
C11 was a Very Bad Idea. It might be possible in some projects, but in the 
current VLC code base, that does not seem to be the case.

> [which] gives us a few things for free.

Admittedly, I am not intimate with C++. Still I do not really what C++98-
compatible features C++11 brings that are not already available in C++98, and 
I find the concept very dubious.

What you do get is the assurance that the code works with C++11, but you lose 
the assurance of that the code works with C++98.

-- 
Rémi Denis-Courmont
http://www.remlab.net/