Date: Thu, 29 Apr 2021 17:17:31 -0400
On Thu, Apr 29, 2021 at 11:22 AM Giuseppe D'Angelo via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> Hi,
>
> On 29/04/2021 15:56, Jason McKesson via Std-Discussion wrote:
> >> Well... "sure"? Does this now make std::vector unimplementable in the
> >> C++ language, as it requires implementation "magic" to perform 3)?
> > Um, no. A pointer becoming invalid is not something you can detect.
> > Being invalid means that UB will happen if you try to use it. And UB
> > could include everything "working" as you would expect.
>
> I didn't say I can detect it...
>
> ... I said that if I implement a conforming `vector` myself, I will lack
> the "magic" to make pointers into my vector invalidated.
And my point is that you don't need to *make* them invalid, precisely
because nobody can *detect* that they became invalid. User code isn't
allowed to use them, so you don't need to do anything. Neither do
`vector` implementations. You will find exactly zero code in
`std::vector` implementations that magically mark those pointers as
"invalid".
They're invalid by convention, not by actual execution of something.
> My users still
> can't use those pointers (because that's the specification), but for the
> compiler, those pointers will be 100% valid and so it won't be able to
> apply the same (theoretical) reasoning and optimizations that it can
> apply for `std::vector` itself.
>
> Since I clearly also want those optimizations, is there any reason for
> C++ not providing such a thing to end-users, so that can I also have the
> magic "invalidate these pointers" facility for my own containers?
Um, I don't know what you're talking about here. Pointers being
invalid means that you're not allowed to use them. They don't
magically make code faster; what they allow the compiler to do is to
not care about code that tries to use them past that point.
But since a user who upholds their end of the contract won't be using
them past that point, then the question is moot. There will be no code
for the compiler to ignore, so there will be nothing to optimize away.
<std-discussion_at_[hidden]> wrote:
>
> Hi,
>
> On 29/04/2021 15:56, Jason McKesson via Std-Discussion wrote:
> >> Well... "sure"? Does this now make std::vector unimplementable in the
> >> C++ language, as it requires implementation "magic" to perform 3)?
> > Um, no. A pointer becoming invalid is not something you can detect.
> > Being invalid means that UB will happen if you try to use it. And UB
> > could include everything "working" as you would expect.
>
> I didn't say I can detect it...
>
> ... I said that if I implement a conforming `vector` myself, I will lack
> the "magic" to make pointers into my vector invalidated.
And my point is that you don't need to *make* them invalid, precisely
because nobody can *detect* that they became invalid. User code isn't
allowed to use them, so you don't need to do anything. Neither do
`vector` implementations. You will find exactly zero code in
`std::vector` implementations that magically mark those pointers as
"invalid".
They're invalid by convention, not by actual execution of something.
> My users still
> can't use those pointers (because that's the specification), but for the
> compiler, those pointers will be 100% valid and so it won't be able to
> apply the same (theoretical) reasoning and optimizations that it can
> apply for `std::vector` itself.
>
> Since I clearly also want those optimizations, is there any reason for
> C++ not providing such a thing to end-users, so that can I also have the
> magic "invalidate these pointers" facility for my own containers?
Um, I don't know what you're talking about here. Pointers being
invalid means that you're not allowed to use them. They don't
magically make code faster; what they allow the compiler to do is to
not care about code that tries to use them past that point.
But since a user who upholds their end of the contract won't be using
them past that point, then the question is moot. There will be no code
for the compiler to ignore, so there will be nothing to optimize away.
Received on 2021-04-29 16:17:45