2017-06-02 19:24 GMT+02:00 Peter Dimov via Boost
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. Regards, &rzej;