Re: [boost] [atomic] Structs with default constructor

Subject: Re: [boost] [atomic] Structs with default constructor
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-07-07 10:17:14

On Monday 07 July 2014 15:53:21 Tim Blechmann wrote:
> >>>> Boost.Atomic 1.55 accepted structs with a user-defined default
> >>>> constructor
> >>>> as template argument, the version from the 1.56 test build doesn't
> >>>> (because
> >>>> of the union_cast). Is this by design? I could be wrong, but I thought
> >>>> the
> >>>> only requirement for structs to use them in atomics was that they were
> >>>> trivially coyable.
> >>> 
> >>> Yes, this is the property of the current implementation. The type has to
> >>> be
> >>> trivial (3.9/9). The previous versions compiled with types with
> >>> non-trivial
> >>> default constructors but the constructors were not actually called.
> >> 
> >> andrey, the standard requires that the type is trivially copyable, but
> >> it allows non-trivial constructors. this should be fixed for the 1.56
> >> release, especially as it breaks existing code (including
> >> boost.lockfree).
> > 
> > Yes, I know the standard requires the type to be trivially copyable. My
> > point is that the code did not support this previously and silently
> > misbehaved, and now it explicitly fails to compile. The code was broken
> > long before 1.56.
> it used to work flawless with the tagged_ptr/tagged_index structs in
> boost.lockfree, though this did not touch any borderline cases, which
> require special care for alignment.
>
> > Implementing support for non-trivial default constructors is possible but
> > tricky - mostly because we have to explicitly call the default constructor
> > on the storage, and while doing this we have to deal with alignment
> > issues. Also I don't know if we should also explicitly call the
> > destructor. I'm willing to resolve this at some point, just not sure that
> > 1.56 is the deadline I'm able to target.
> 
> this will lead to the point that boost.lockfree is broken on the clang
> toolchain, because the issue which you introduced is *exactly* the same
> issue as with std::atomic in libc++ [1].
> 
> i know more than one project for which this issue is a showstopper ...

I didn't see that Boost.Lockfree was broken. Ok, I'll try to resolve this 
before the release.