Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Martin Sebor <msebor at gmail dot com>]

On 12/13/2016 02:32 PM, Jason Merrill wrote:
> On 12/13/2016 03:25 PM, Martin Sebor wrote:
> > On 12/13/2016 12:06 PM, Jason Merrill wrote:
> > > On 12/09/2016 07:46 PM, Martin Sebor wrote:
> > > > On 12/09/2016 02:49 PM, Jason Merrill wrote:
> > > > > On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor <msebor@gmail.com>
> > > > > wrote:
> > > > > > For flexible array members, because they're not in C++, we get to
> > > > > > make up the rules that make the most sense to us.  IMO, they should
> > > > > > fit in well with the rest of the language.
> > > > >
> > > > > I disagree; we should support C code, but flexible arrays don't really
> > > > > fit with the C++ object model, so I don't think trying to do anything
> > > > > clever with them in constructors is worthwhile.
> > > >
> > > > With the suggested approach the array becomes just an ordinary member.
> > > > It's not a flexible array member anymore because its bound is deduced
> > > > from the initializer (it just looks like one).  The NSDMI char a[] =
> > > > "foo" syntax is just a shorthand for char a[4] = "foo".
> > >
> > > That would mean that the size of the class varies with its initializer,
> > > which again gets into not fitting with the C++ object model.
> >
> > Okay, I accept the challenge of finding a case where the size
> > of a class depends on an initializer expression :)
> >
> > Here's one:
> >
> >   constexpr long f (int) { return 1; }
> >   constexpr long f (long) { return LONG_MAX; };
> >
> >   struct A {   // sizeof (A) == 4
> >     enum E { i = f (0) } e;
> >   };
> >
> >   struct B {   // sizeof (B) == 8
> >     enum E { i = f (0L) } e;
> >   };
> >
> > It's not exactly the same but I think it's close enough to argue
> > that deducing the array size from its initializer wouldn't go
> > against the established model.
>
> I don't see the similarity; A and B both have constant size.

Sure, just as C and D below do today

  struct C {   // sizeof (C) == 4
    char a[4] = "abc";
  };

  struct D {   // sizeof (D) == 8
    char a[8] = "abcdefg";
  };

and as would E and F below with what I suggest:

  struct E {   // sizeof (E) == 4
    char a[] = "abc";
  };

  struct F {   // sizeof (F) == 8
    char a[] = "abcdefg";
  };

Where is the disconnect?

I'm not suggesting that the size of an object of a class change
depending on how the member array is initialized in each ctor
initializer list (if that's how it came across).

Martin