Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-31 15:11:43

on Thu Jan 31 2013, Paul Smith <> wrote:

> On Thu, Jan 31, 2013 at 3:22 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Mon Jan 28 2013, Paul Smith <> wrote:
>>> This issue has been discussed more than once before, and nothing I say
>>> here is my own opinion, so please don't take it out on me.
>>> For example, see N3264 (CH-18 and US-85: Clarifying the state of
>>> moved-from objects (Revision 1)):
>>>> and Dave confirms that,
>>> I don't want to read into what Dave said too much, because he's here
>>> and he can clarify it. But I believe what he said is that specific
>>> algorithms, in their own localized context, practically only require
>>> destructibility and assignability. And even then,

I was disavowing this part because I don't claim to know it for sure:

>>> it's not something the standard actually guarantees in general,
>>> though, and the requirements are still much stricter, perhaps
>>> superfluously so.

and I was disavowing this part because I disagree with it:

>>> it's a good selling point for having destructive move semantics -
>> That doesn't sound like anything I meant to say, but I do agree fully
>> with the resolutions (if not the NB comments) in the paper cited above.
> Then what did you mean?

See above.

> Btw, the reason why I brought up this paper was because I couldn't
> help noticing the similarity between the case mentioned there and what
> we have here. The US NB was requesting that the standard would require
> standard-library types (or maybe types in general) only to be
> destructible and assignable after a move. The case they mentioned was
> containers that allocate their sentinel nodes dynamically. If the
> container has to remain valid after a move, the move constructor has
> to allocate sentinel nodes "for nothing".
> The resolution was, AFAICT: No. Moved-from library types should remain
> valid. If dynamically allocated sentinel nodes are your implementation
> strategy, you have to bite the bullet (Which is, btw, what the
> Microsoft implementation actually does, at least as of MSVC 10. Could
> someone please check if they changed it in 11? Run the attached file,
> you should see two allocations).
> The resolution wasn't "let's say that moved-from types should only
> remain destructible and assignable", and it wasn't "let's add a
> singular value to std::list".

Right. And that's the resolution I fought for.

> Ofcourse, boost isn't the standard library and you're not bound by any
> of this. Still, it's awkward to have the standard pull in one
> direction and boost pull in the other one.

I agree, it would be.

Dave Abrahams
BoostPro Computing                  Software Development        Training             Clang/LLVM/EDG Compilers  C++  Boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at