Le 02/06/2017 à 19:24, Peter Dimov via Boost a écrit :
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 not be against an implementation that returns nullptr of operator-> as far as this is not documented and something the user could use. If returning a nulptr is the best thing that we can do today in order to help the current tools to catch UB, why not. I don't agree on documenting it, because this could make some user code more complex. When you have a narrow contract you know that the check must be done before. If you document that it the user can be tempted to check it. Well operator-> is particular in some way as the user doesn't use to use it as x.operator->(). Consider for a moment that some compiler manage better UB when we do a check and assert for unreachable code (as other are suggesting). Requiring a nullptr as result will forbid this implementation, isn't it? My question is, why do you consider that it is good to document it? Vicente