Date: Thu, 29 Apr 2021 10:58:59 -0400
On 4/28/21 3:07 PM, Giuseppe D'Angelo via Std-Discussion wrote:
> Hello,
>
> On 28/04/2021 20:09, Edward Catmur via Std-Discussion wrote:
>> Except, of course, what happens is that when the compiler detects
>> one of these uses of an invalidated pointer, it silently uses the
>> undefined behavior permission to subvert the program and produce
>> wrong results from the point of view of the programmer. That is, it
>> opens up a new class of silent and deadly errors that would not be
>> there without this pointer invalidation.
>>
>> Another way to look at it is that by exhaustively testing your
>> program with sanitizers enabled, you guarantee that it lacks a class
>> of bugs and thus that it is safe and advantageous for the optimizer
>> to transform your program accordingly.
>>
>> I do have some sympathy for your point of view... but we need the
>> optimizations.
>
> I 100% agree with the above point when it comes to iterators. I may
> also agree, in principle, with pointers/references. But, let me bite
> the bullet here: is there any implementation where this actually happens?
>
> To be honest, I was more under the impression that the limitation for
> pointers/references was the consequence of an "earlier" lifetime
> model, more than an actual room for optimization. I find it hard to
> mentally conciliate that the compiler cannot do _any_ optimization if
> you do the 100% equivalent work, say, in your own implementation of a
> `vector` (because of the [basic.life] wording); while instead the
> Standard Library a blank check for `std::vector` itself. If anything,
> I'd expect a `std::invalidate(ptr)` so that I can also apply the same
> optimization to my own containers...?
I see the C++ object model as being more fundamental to enabling
symbolic evaluation and constant evaluation than for enabling
optimization (though it does enable more optimizations than we would
otherwise have) and bug finding (enabled via sanitizers). Allowing for
pointers to silently change which object is referred to would complicate
these forms of evaluation.
Tom.
> Hello,
>
> On 28/04/2021 20:09, Edward Catmur via Std-Discussion wrote:
>> Except, of course, what happens is that when the compiler detects
>> one of these uses of an invalidated pointer, it silently uses the
>> undefined behavior permission to subvert the program and produce
>> wrong results from the point of view of the programmer. That is, it
>> opens up a new class of silent and deadly errors that would not be
>> there without this pointer invalidation.
>>
>> Another way to look at it is that by exhaustively testing your
>> program with sanitizers enabled, you guarantee that it lacks a class
>> of bugs and thus that it is safe and advantageous for the optimizer
>> to transform your program accordingly.
>>
>> I do have some sympathy for your point of view... but we need the
>> optimizations.
>
> I 100% agree with the above point when it comes to iterators. I may
> also agree, in principle, with pointers/references. But, let me bite
> the bullet here: is there any implementation where this actually happens?
>
> To be honest, I was more under the impression that the limitation for
> pointers/references was the consequence of an "earlier" lifetime
> model, more than an actual room for optimization. I find it hard to
> mentally conciliate that the compiler cannot do _any_ optimization if
> you do the 100% equivalent work, say, in your own implementation of a
> `vector` (because of the [basic.life] wording); while instead the
> Standard Library a blank check for `std::vector` itself. If anything,
> I'd expect a `std::invalidate(ptr)` so that I can also apply the same
> optimization to my own containers...?
I see the C++ object model as being more fundamental to enabling
symbolic evaluation and constant evaluation than for enabling
optimization (though it does enable more optimizations than we would
otherwise have) and bug finding (enabled via sanitizers). Allowing for
pointers to silently change which object is referred to would complicate
these forms of evaluation.
Tom.
Received on 2021-04-29 09:59:03