On Fri, Jan 25, 2013 at 2:32 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Jan 21 2013, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
On Mon, Jan 21, 2013 at 6:12 PM, Joel de Guzman <djowel@gmail.com> wrote:
This notion of a "valid" state is not clear to begin with anyway and many say it depends on the
On Monday 21 January 2013 19:06:32 Paul Smith wrote: library
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? From my perspective the class invariants are defined such that the elements are stored and order is maintained. This is such a core class-invariant for the containers under discussion that it seems absurd to consider breaking it. It isn't merely a matter of compatibility, it is a matter of design coherence. The NaN example is explainable by using Design by Contract too. The pre-conditions of the associative container operations are such that the key must not be NaN. Hence the class invariants are maintained and the world is full of unicorns and rainbows. However once NaNs are input, the class invariants are not maintained. This is entirely reasonable.
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
My vote is that we shouldn't even consider allowing the class invariants for ordered containers to be broken. I cannot imagine a motivation for allowing them to be broken. I suspect this may be a symptom of my failure to comprehend part of this discussion. Neil Groves