Sujet : Re: 80386 C compiler
De : jameskuyper (at) *nospam* alumni.caltech.edu (James Kuyper)
Groupes : comp.lang.cDate : 28. Nov 2024, 00:07:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vi88n4$74j9$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla Thunderbird
On 11/27/24 16:52, Kaz Kylheku wrote:
On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/27/24 14:42, Kaz Kylheku wrote:
...
The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.
>
That's not an inconsistency, it's a deliberate choice to give
implementations freedom to use whichever order is most convenient.
Implementations are not given freedom about initialization order;
in { A, B } the initialization implied by A happens before B.
Granting a freedom here while taking it away there is inconsistent.
Expression B may rely on the initialization A having completed, but
not on the effects of A having been settled.
I'm sorry - I thought you meant that they were logically inconsistent.
What you're actually saying is more like stylistically inconsistent.
In C90, the order in which the initializers were evaluated didn't
matter, because they were required to be static initializers. It was
only in C99 that they were allowed to be arbitrary expressions.
However, in the same version of the standard, designated initializers
were added. Designated initializers are allowed to update elements in a
different order from their order in memory, and to initialize the same
element multiple times, with only the final initialization actually
occurring. This can be convenient for setting up a rule and then adding
exceptions to that rule. 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.