On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor <mse...@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".
The only open question I can think of is what to do about the (IMO)
unlikely corner case where the array isn't initialized in the class
but rather in two or more ctors that are defined in their own
translation units:
struct S {
char a[];
S (int);
S (int, int);
};
// in foo.C
S::S (int): a ("1") { }
// in bar.C
S::S (int, int): a ("12") { }
I think warning on it or even rejecting it would be fine.
This approach would make "flexible array members" (or their C++
lookalikes as per the above) safer to use in classes with ctors
than the currently accepted alternative because it would let GCC
detect and diagnose overflows that can't be detected without
knowing the array size:
S::S (int) { strcpy (a, "1234"); }
Martin
