Re: 80386 C compiler

Liste des GroupesRevenir à cl c  
Sujet : Re: 80386 C compiler
De : jameskuyper (at) *nospam* alumni.caltech.edu (James Kuyper)
Groupes : comp.lang.c
Date : 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.


Date Sujet#  Auteur
24 Nov 24 * 80386 C compiler36Paul Edwards
24 Nov 24 +* Re: 80386 C compiler6fir
24 Nov 24 i+* Re: 80386 C compiler2fir
25 Nov 24 ii`- Re: 80386 C compiler1Paul Edwards
24 Nov 24 i`* Re: 80386 C compiler3Bart
25 Nov 24 i `* Re: 80386 C compiler2BGB
25 Nov 24 i  `- Re: 80386 C compiler1Paul Edwards
24 Nov 24 +* Re: 80386 C compiler24Janis Papanagnou
25 Nov 24 i`* Re: 80386 C compiler23Paul Edwards
25 Nov 24 i `* Re: 80386 C compiler22Kaz Kylheku
25 Nov 24 i  +* Re: 80386 C compiler20Rosario19
26 Nov 24 i  i`* Re: 80386 C compiler19Kaz Kylheku
26 Nov 24 i  i +* Re: 80386 C compiler7Keith Thompson
26 Nov 24 i  i i+* Re: 80386 C compiler5Paul Edwards
27 Nov 24 i  i ii`* Re: 80386 C compiler4Keith Thompson
27 Nov 24 i  i ii `* Re: 80386 C compiler3Paul Edwards
27 Nov 24 i  i ii  `* Re: 80386 C compiler2Keith Thompson
27 Nov 24 i  i ii   `- Re: 80386 C compiler1Paul Edwards
28 Nov 24 i  i i`- Re: 80386 C compiler1Tim Rentsch
27 Nov 24 i  i +* Re: 80386 C compiler9David Brown
27 Nov 24 i  i i`* Re: 80386 C compiler8Kaz Kylheku
27 Nov 24 i  i i +* Re: 80386 C compiler6James Kuyper
27 Nov 24 i  i i i`* Re: 80386 C compiler5Kaz Kylheku
28 Nov 24 i  i i i `* Re: 80386 C compiler4James Kuyper
30 Nov 24 i  i i i  `* Re: 80386 C compiler3Kaz Kylheku
30 Nov 24 i  i i i   +- Re: 80386 C compiler1Tim Rentsch
30 Nov 24 i  i i i   `- Re: 80386 C compiler1James Kuyper
28 Nov 24 i  i i `- Re: 80386 C compiler1David Brown
28 Nov 24 i  i +- Re: 80386 C compiler1Tim Rentsch
30 Nov 24 i  i `- Re: 80386 C compiler1Rosario19
26 Nov 24 i  `- Re: 80386 C compiler1Paul Edwards
25 Nov 24 `* Re: 80386 C compiler5Lynn McGuire
26 Nov 24  `* Re: 80386 C compiler4Keith Thompson
26 Nov 24   `* Re: 80386 C compiler3Lynn McGuire
26 Nov 24    `* Re: 80386 C compiler2Keith Thompson
26 Nov 24     `- Re: 80386 C compiler1BGB

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal