Sujet : Re: 80386 C compiler
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.cDate : 30. Nov 2024, 06:00:20
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <865xo5pb8b.fsf@linuxsc.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Kaz Kylheku <
643-408-1753@kylheku.com> writes:
On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
If there weren't a rule mandating the order in which initializers
were applied, when two or more initializers affect the same
object, it wouldn't be possible to be certain which one overrode
the others.
That's wrong. The priority rule for initializing the same subobject
depends not on order of evaluation but on syntactic order. There
doesn't have to be a rule for evaluation order to make the order
of subobject overriding be well defined.
It would make sense for that simply to be a constraint violation;
two initializations for the same object are being requested.
It isn't that simple. There are situations where overriding the
initialization of a particular subobject makes sense, and is
useful. Example:
typedef struct { int x, y; } Bas;
typedef struct { Bas b[2]; } Foo;
Foo
sample_foo( Bas b ){
Foo foo = { b, b, .b[1].y = -1 };
return foo;
}
The subobject .b[1].y is overridden, but we can't take the previous
initialization of .b[1] without changing the semantics.