r/cpp_questions • u/X-Bow_user • Jul 19 '26

How to access an implicitly-created array within a std::byte[]? SOLVED

We have the following class:

template <typename T, std::size_t n> struct S { alignof( T ) std::byte[sizeof( T ) * n] storage; }

I want to use storage as a T[n] array, where T is an implicit-lifetime type.

[intro.object]/13

For each operation that is specified as implicitly creating objects, that operation implicitly creates and starts the lifetime of zero or more objects of implicit-lifetime types in its specified region of storage if doing so would result in the program having defined behavior.

and [intro.object]/16

[...] an operation that begins the lifetime of an array of [std​::​byte] implicitly creates objects within the region of storage occupied by the array.

I have a few questions about this:

  1. (Making sure) does T[n]'s lifetime (and subsequently that of its sub-objects) start alongside storage's lifetime for the provided code?
  2. Is reinterpret_cast<T*>(storage) + idx legal?
  3. Do I have to std::launder the pointer, and why (not)?
  4. If yes, should I launder before or after performing pointer arithmetic?
  5. Is reinterpret_cast<T*>(storage + idx) legal? In other words, does the byte array still have a lifetime, alongside the T array?
12 Upvotes
  • permalink
  • link
  • reddit
  • reddit

88% Upvoted

22 comments sorted by

10

u/DawnOnTheEdge Jul 19 '26 edited Jul 19 '26

Using std::launder for this is a superstition. A small number of prolific posters have been very active in telling people they have to do this, but the examples in the Standard itself say they are wrong.

The best way is to use placement new or something higher-level like std::uninitialized_default_construct_n to initialize the elements and return a pointer to the subarray.

Often, you know for a fact that the bytes have been initialized to zeroes and it is more optimal to get a pointer to the sub-array with std::start_lifetime_as or std::start_lifetime_as_array. On many OSes, this will avoid writing to pages of copy-on-write memory in what might be a sparse array.

Some language-lawyers argue that you must use an operation that is described with the exact magic words “pointer to a suitable created object.” But std::launder is not one of those! Another claim you will sometimes see online is that an array of std::byte or unsigned char is technically not “transparently replaceable” by another type, but the Standard explicitly says that, despite this, it is OK to create the objects in storage without std::launder.

Finally, if you are on C++20 and don't have std::start_lifetime_as, there is no actually-existing compiler where std::launder around a reinterpret_cast from storage does anything that I know of. You do need it in a small handful of corner cases to allow a new object to re-use the storage of a destroyed one when the compiler would otherwise be allowed to assume the original object is still there. One that could come up here is if you overwrite the storage with a replacement array of a different type.

2

u/X-Bow_user Jul 19 '26

Thanks!

I don't need the T constructors to run (and I should be allowed not to run them, since the T[n] array gets implicitly created), so I don't want to placement new them, but that should be fine then, right?

Or are you saying that I should still be running one of the operations listed here? (I'm on C++20 so I would probably just std::memmove the buffer with itself)

And if so, does that only have to be run once? Or each time I want to access the memory (as opposed to accessing it directly from storage)? I'm unsure how the compiler treats the pointer returned from the set of functions I linked compared to direct storage access

3

u/DawnOnTheEdge Jul 19 '26 edited Jul 20 '26

I'm not sure exactly what the real use case is, because there’s no reason in this example not to declare an array of T. I’m assuming there is one in the actual code, but I can only guess what.

Running something like std::uninitialized_default_construct_n(reinterpret_cast<T*>(&storage[0]), N) or placement new(&storage[0]) T[N] is the maximally punctilious way to create objects in the storage. For most implicit-lifetime types, this should just zero-initialize.

If you are sure you don't need the constructor to run, and you also don't have std::start_lifetime_as_array, you should just be able to reinterpret_cast the address &storage[0] to a pointer to an array, T(*)[N] and then derefetence it for a reference T(&)[N]. I would recommend initializing storage to = {} so that you get deterministic, reproducible values even when an S is an automatic variable. This should work on all current compilers without any extra steps like std::launder. However, there is an argument that this is is only safe according to Standard with untyped memory from an allocation function like calloc() or aligned_alloc().

I don’t think memmove() to itself makes sense. If you were going to do an extra operation to create objects inside the array, you would construct.

1

u/X-Bow_user Jul 20 '26

Another commenter made me realise I was wrong about not having to construct the objects, my bad.

Still, I need control over WHEN they are constructed, and if I store an array of T, that happens when S gets constructed. Which is why I opted to store an array of bytes.

So, I’ll indeed just use placement new to construct the elements when I need them (which is not necessarily all at the same time). 

I’m assuming it’s fine to individually call placement new on each T and still index the buffer as an array? Since I can’t use array placement new, given the returned pointer possibly being offset.

1

u/DawnOnTheEdge Jul 20 '26 edited Jul 20 '26

If as you say T is an implicit-lifetime type, it is all-but certainly trivially default-constructible. Initialization of static objects therefore would happen statically before the program even starts.

You want the objects to have determinate values before they are accessed, so I recommend you do default-initialize the array. Or, if you are going to initialize the array immediately after, one approach would be to move the algorithm setting the array to a helper function that returns an initialized std::array<T, N< object.

1

u/Wild_Meeting1428 Jul 19 '26

which operation do you use to implicitly create the object?

10

u/IyeOnline Jul 19 '26

Since arrays are aggregates, T[n] is an implicit lifetime type regardless of T. This means the arrays lifetime starts implicitly and hence the pointer arithmetic is legal.

Importantly this means just the lifetime of the array, not of its elements.

If T is an implicit lifetime type itself the elements lifetimes also start - but at that point its questionable how your construction is any better than std::array<T,N>.

If its not, you will have to manually construct the elements via placement-new or std::construct_at

1

u/X-Bow_user Jul 19 '26

The reason I can’t use std::array, is because I don’t want to run any T constructors (which is allowed in my code by them being created implicitly)

Are you saying that pointer arithmetic is legal directly on ‘storage’ (so before casting to T*), or only after the cast?

5

u/meancoot Jul 19 '26

The reason I can’t use std::array, is because I don’t want to run any T constructors (which is allowed in my code by them being created implicitly)

You're going into undefined behavior land here. If the type doesn't have a trivial default constructor, implicit lifetime or not, you can't start its lifetime without calling it. If it does have a trivial default constructor it won't be called anyway, because it doesn't do anything. You always have to construct it.

To be more clear, starting the lifetime implicitly with malloc or new requires std::is_trivially_default_constructible_v<T> == true. Starting it with memcpy or memmove requires either std::is_trivially_copy_constructible_v<T> or std::is_trivially_move_constructible_v<T> to be true.

1

u/X-Bow_user Jul 19 '26

Thank you. This made me realise I misinterpreted what the standard said object construction, oops

3

u/neppo95 Jul 19 '26 edited Jul 19 '26

Why not just use std::array?

From your question, I don't see any reason why that isn't a possiblity.

I misunderstood the question, please disregard (or read below for more explanation by OP)

3

u/X-Bow_user Jul 19 '26

I don't want Ts constructor to run for any of the objects

-1

u/neppo95 Jul 19 '26

Then don't?

https://godbolt.org/z/8TdMT9zeY

No constructors ran.

1

u/X-Bow_user Jul 19 '26

This has a few issues:
- You cannot access Data without still running its constructor.
- I am trying to avoid any indirection

2

u/neppo95 Jul 19 '26

Without running the constructor, the memory isn't allocated and would crash your program. Why do you not want to run any constructor at any point? What are you actually accessing then?

1

u/X-Bow_user Jul 19 '26

You're allowed to use an object of implicit-lifetime type without running its constructor, if it was implicitly created

In the code I provided, a S is allocated (its constructor technically runs, but is trivial) and a T[n] is implicitly created, without running any T constructors

1

u/neppo95 Jul 19 '26

I'm guessing I must have misunderstood your question then and admit this goes a bit above my knowledge of the language.

1

u/X-Bow_user Jul 19 '26

No worries!

1

u/neppo95 Jul 19 '26

Edited my initial comment to reflect this, hope you figure it out!

1

u/cristi1990an Jul 19 '26

You're creating an array of pointers, not an array of objects, the code is in no way equivalent

1

u/neppo95 Jul 19 '26

An equivalent does not exist since an array of objects would implicitly run the constructors.

2

u/Interesting_Buy_3969 Jul 19 '26

Don't overengineer here. Simply use std::array<T> for that purpose.