C++ Logo


Advanced search

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

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Thu, 17 Aug 2023 17:34:26 -0400
On Thu, Aug 17, 2023 at 4:21 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
> On Thu, Aug 17, 2023 at 9:08 PM Lénárd Szolnoki wrote:
> >
> > foo(a, pretend_is_std_array(a.arr)); // breaking the aliasing
> > assumption here
> I'll get to the point here:
> How about we explicitly write in the C++26 Standard that T[len] and
> array<T,len> are ABI-compatible,

Have you looked at the existing ABIs to see if this is viable? Because
in order for this to even be *considered*, then the following must be
true today:

struct A
  char ca1[3];
  char ca2[3];

struct B
  std::array<char, 3> ca1;
  std::array<char, 3> ca2;

static_assert(sizeof(A) == sizeof(B));

If any C++-supporting platform has an ABI such that a struct
containing only an array does not *always* have the same size (and
alignment) as the array itself, then what you're suggesting is an
ABI-break. And that's... bad.

> and also provide two functions:
> stdarray_to_array
> array_to_stdarray
> , both of which return a reference to an object that doesn't
> malfunction where you have anti-aliasing optimisations.

Um, no. While I appreciate the idea behind making `std::array`
isomorphic with language arrays, *this* suggestion is something that
should never happen.

If the two types are isomorphic, they should still be *different*
types. There's no reason to allow them to alias like that. If you want
to convert between them, use a `bitcast` (or rather, an array-based
version of the same idea).

Received on 2023-08-17 21:34:38