Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-03 10:00:35
2017-06-02 19:24 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:
> Andrzej Krzemienski wrote:
> > Not merely potential. Actual slowdown on the order of 100. You should >
>> read it as "as much as we'd like to define the behavior of operator, >
>> doing so would be prohibitively expensive, so we won't."
>> Why the same argument with "compiler will see that I am checking the same
>> condition twice, and remove redundant checks" does not apply here?
> Because we can test it and see that it doesn't. This is an empirical
> argument, not a theoretical argument. "But it's the same here!" Well no, it
> isn't, we can measure it.
> > We have no tradition in expressing the above, so within the current >
>> vocabulary I prefer guaranteeing the `nullptr` instead of leaving the >
>> behavior undefined in the hope that it will end up being defined to the >
>> above. (It won't be.)
>> That is true, "it wont' be". And that was never the goal.
>> But what is the gain with the nullptr trick? someone can still cause UB
>> with it, so it does not seem much "safer". Are you increasing the chances
>> that it will be trapped by the operating system?
> It's again a practical argument - we know what it does. In principle, it
> should be the same, but it isn't. We know that if we write the
> specification this way, so and so happens, and if we write it another way,
> different things occur. :-)
Peter, I do not understand what you are trying to say here. You say you
have observed some useful behavior when your trick with operator-> is
applied. I am asking what it is. It is still an UB when used, so there must
be something to it. My guess would be that UB on null pointer is more
tool-friendly than UB on just any bad pointer. But if it should be the
case, why did you say you would like the same trick in shared_ptr? It deals
with dereferencing a nullptr both with and wothout your hack.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk