Subject: Re: [boost] [variant] Please vote for behavior
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-25 10:21:47
on Fri Jan 25 2013, Neil Groves <neil-AT-grovescomputing.com> wrote:
> On Fri, Jan 25, 2013 at 2:32 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Mon Jan 21 2013, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>> > On Monday 21 January 2013 19:06:32 Paul Smith wrote:
>> >> On Mon, Jan 21, 2013 at 6:12 PM, Joel de Guzman <djowel_at_[hidden]>
>> >> > This notion of a "valid" state
>> >> > is not clear to begin with anyway and many say it depends on the
>> >> > to define what "valid" means. The case of NaN is a very clear example
>> >> > of a perfectly "valid" state similar to what we have here.
>> >> I'm not sure what the NaN example supposed to convey? I think Nevin
>> >> brought it up to show that std::less<double> is not a weak partial
>> >> order. And guess what, it technically isn't! Try to put NaNs inside an
>> >> associative container and watch the world collapse. The big difference
>> >> is that no operation on non-NaNs that the container performs ever
>> >> produces a NaN out of thin air.
>> > Why would a container try to order moved-from elements?
>> Moved-from elements can be left there due to exceptions propagating out
>> of the code. That's a *new* state that wasn't allowed before
>> move-enabling, so if these moved-from elements have a state outside the
>> former invariants, it will break some code.
> Isn't leaving the class with it's invariants broken simply a defect?
Yes. IIUC the question here is whether the invariant of variant [;-)]
shall be weakened to accommodate efficient move semantics, thereby
breaking some code, or not, at some cost (the specific costs to be
incurred by various strategies presently under discussion).
But I have to admit, I haven't been reading the thread all that
carefully, so I could be mis-understanding completely.
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk