Re: [boost] Fw: [atomic] review results

Subject: Re: [boost] Fw: [atomic] review results
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-11-08 14:22:33

On Tuesday, November 08, 2011 10:53:09 Helge Bahmann wrote:
> Hi Tim,
> 
> > * compilers are not required to implement atomics so that
> > sizeof(atomic<T>) == sizeof (T). so the size of a data structure may
> > change when switching compilers.
> 
> Yes that's right, however I trust that ABI conventions will be worked out
> per platform eventually -- people will consider inability to mix
> icc/gcc/clang/whatever at least on a shared-library level as unacceptable,
> and currently it works rather well. Also note that the intent of C++11 is to
> make these low-level structures compatible with C1X so there really is not
> that much room.
> 
> I think that there is value in trying to maintain sizeof(boost::atomic<T>)
> == sizeof(std::atomic<T>) whatever this is going to mean per platform, and
> part of the thing I have in my mind is indeed interprocess-safety. I also
> don't think that Boost.Atomic it is in that state currently, but I am a bit
> reluctant to make a decision that might shut down this path forever.

I'm not trying to convert you or anything, but to me requirement of binary 
compatibility between std::atomic and boost::atomic looks excessive.

The wish for binary compatibility between different implementations of 
std::atomic, as well as other STL components is quite understandable, although 
I doubt that in reality this is achieved beyond the most trivial cases, such 
as std::pair or std::auto_ptr instances. These implementations denote the same 
type and from the linker perspective different implementations of std::atomic 
will still be std::atomic and nothing else. ODR is violated in this case but 
it might slide.

But when you try to operate on boost::atomic as it would be std::atomic, this 
just looks totally wrong to me. These types are different, so the linker (or 
compiler for that matter) will never let it go. So the developer will have to 
do reinterpret_casts explicitly and I believe no sane developer will do that 
and hope it to work.