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

[Hugo Beauzée-Luyssen]

On 22/06/2015 18:14, Rémi Denis-Courmont wrote:
> Le lundi 22 juin 2015, 17:42:59 Hugo Beauzée-Luyssen a écrit :
>> In order to be able to use atomic_load & co (at least on GCC, I haven't
>> checked clang), we need to specify ourselves that atomic_int is an
>> explicit specialization of std::atomic<T>,
>
> No, that cannot work. It would reintroduce the exact bug I was trying to fix
> yesterday. We need compatible definitions of atomic types in C and C++, and so
> regardless of the standard version setting of the compiler. That is due to
> vlc_object_alive(), picture_t, etc crossing language and binary boundaries.
>
> 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.

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

>> 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*, 
which I believe is a good idea to prepare to a later point of time, when 
we decide to require C++11, and gives us a few things for free.

-- 
Hugo Beauzée-Luyssen