C++ Logo


Advanced search

Re: [std-proposals] Only reason I don't use std::array

From: Tom Honermann <tom_at_[hidden]>
Date: Thu, 17 Aug 2023 14:39:31 -0400
On 8/17/23 2:01 PM, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Thursday, August 17, 2023, Tom Honermann wrote:
> > The code has undefined behavior since
> > no object of std::array<T,len> actually
> > exists at the address returned by
> > pretend_is_std_array().
> Yeah but something ABI-compatible with it does. But even if it were
> zero-initialised memory, that can be an array of int's all set to zero.
> > While the code might exhibit the behavior you
> > want today, there is no guarantee that a future
> > compiler upgrade won't include optimizer
> > changes that cause it to behave differently.
> > Violating the C++ object model is not
> > something I would recommend.
> Change the pointer to 'a pointer to volatile' and then use
> std::launder on it.
> By the way I've only ever seen one example of C++ code that behaves
> differently when you use 'launder', and it involved a constructor
> using 'placement new' to invoke a constructor belonging to another
> class on the current object, something like:
> MyClass::MyClass(void)
> {
> ::new(this) SomeOtherClass();
> }
> The use of 'launder' prevented caching of the vtable -- which can also
> be achieved by making the object 'volatile' like I did in a puzzle I
> composed on Codewars:
> https://www.codewars.com/kata/6359c81e00fba2852618a1cb/
> The object model in C++ isn't as wild and wacky as some people make it
> out to be. There isn't and optimiser up on a lighthouse with a sniper
> rifle waiting for the perfect opportunity to invoke UB.

I agree. Optimizers are not written to take advantage of UB. They are
written in accordance with what the standard specifies as defined
behavior. When code fails to adhere to what the standard specifies, then
optimizers might behave in unexpected ways because a property they rely
on (such as the existence of an object of a certain type) has been violated.

As an analogy, consider what happens when a double free occurs. The
observed behavior will depend on the particular heap implementation that
is being used. The observed behavior might be harmless in a particular
case with a particular version of a particular implementation. But
change the specifics of the double free or the implementation or its
version and the observed behavior might start to include memory
corruption (or missiles firing or nasal demons or ...)


Received on 2023-08-17 18:39:33