Francis Glassborow <francis.glassborow@ntlworld.com> writes:

|>  In article <39CFB7AC.496CBAB8@artquest.net>, Pierre Baillargeon
|>  <pb@artquest.net> writes
|>  >Sorry to ask again, but I have two different opinions from people
|>  >I've learned to trust: you and Ron Natalie. Ron claims that each
|>  >initializer is in its own expression, so there is no undefined
|>  >behavior.

|>  Ron is right. An initialiser is a full expression and so terminates
|>  with a sequence point. That means that there is no undefined
|>  behaviour, however I am pretty sure that the order of evaluation is
|>  indeterminate, but I would be happy to be corrected.

It's an interesting question.  According to the standard, all of the
side effects preceding a sequence point must have taken place before the
sequence point (modulo application of the as if rule).  The problem is
that sequence points are designated by lexical position, not temporal.
Within the body of a function, the mapping of lexical to temporal is
more or less obvious, but otherwise?

I'd guess that the order is meant to be guaranteed.  The order of the
actual initialization is definitly guaranteed, although we tend to only
think about it when there is a user-defined constructor.  We have
definite sequence points.  What makes you think that the order is not
guaranteed?

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dag Henriksson wrote:
>
> "Ron Natalie" <ron@sensor.com> wrote in message
> news:39CBC901.B20A0973@sensor.com...
>
> > > struct CMYK { char c, m, y, k };
> > > void foo ( )
> > > {
> > >    char * data = "hello";
> > >    CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> > > }
> >
> > Each one of these is it's own full expression and hence has a sequence
> > point at the end of it.
>
> I don't think so.
>
>From Standard 1.13

Actually, 1.9p13.

> [ Note: certain context in C++ cause the evaluation of a full-expression
> that results from a syntactic con-
> struct other than expression(5.18). For example, in 8.5 one syntax for
> initializer is
>
> ( expression-list )
>
> but the resulting construct is a function call upon a constructor function
> with expression-list as an argument
> list; such a function call is a full-expression. For example, in 8.5,
> another syntax for initializer is
>
> = initializer-clause
>
> but again the resulting construct might be a function call upon a
> constructor function with one assignment-
> expression as an argument; again, the function call is a full-expression]

CMYK has no constructor that takes four arguments, so if you were using
that interpretation the code would be ill-formed. There is no implicit
function call expression containing the initializers. According to
8.5p14: "If the class is an aggregate (8.5.1) and the initializer clause
is a brace-enclosed list, see 8.5.1", which requires that the
initializer clause be interpreted as "a brace-enclosed comma-separated
list of initializers for the members of the aggregate".
Since there is no constructor call to CMYK(), there's no function-call
expression for the "data++" expressions to a sub-expressions of.
Therefore, they meet the definition of full-expressions.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:39D29118.9B7583DD@wizard.net...
> > > > struct CMYK { char c, m, y, k };
> > > > void foo ( )
> > > > {
> > > >    char * data = "hello";
> > > >    CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> > > > }
> > >
> CMYK has no constructor that takes four arguments, so if you were using
> that interpretation the code would be ill-formed. There is no implicit
> function call expression containing the initializers. According to
> 8.5p14: "If the class is an aggregate (8.5.1) and the initializer clause
> is a brace-enclosed list, see 8.5.1", which requires that the
> initializer clause be interpreted as "a brace-enclosed comma-separated
> list of initializers for the members of the aggregate".
> Since there is no constructor call to CMYK(), there's no function-call
> expression for the "data++" expressions to a sub-expressions of.
> Therefore, they meet the definition of full-expressions.

Right. The two examples from 1.9p13 don't quite match the code
above. But I'm still not convinced that the assignment expression is it's
own full
expressioin.

The initializers are used to copy initialize the members of the CMYK. The
full expressions should be the "syntactic constructs"

CMYK::c = data++;
CMYK::m = data++;
...

Let's change the example a bit:

class C {
C(int);
};

struct S
{
C c;
};
int data = 0;
S s = { data++ };

Here you have the function call. C:C(int) is called to initialize the member
c.
1.9p13 doesn't explicitly say that this, or the CMYK case, is on of the
"certain context" when the full expression is the syntactic construct, but I
don't see why this should be any different.

-- Dag Henriksson




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <39CBC3DF.69A872F4@artquest.net>, Pierre Baillargeon
> <pb@artquest.net> writes
> >struct CMYK { char c, m, y, k };
> >void foo ( )
> >{
> >   char * data = "hello";
> >   CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> >}
> No, that comma is not an operator but just a punctuator. The above code
> has undefined behaviour.

Sorry to ask again, but I have two different opinions from people I've
learned to trust: you and Ron Natalie. Ron claims that each initializer
is in its own expression, so there is no undefined behavior.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39CFB7AC.496CBAB8@artquest.net>,
  Pierre Baillargeon <pb@artquest.net> wrote:
> Francis Glassborow wrote:
> >
> > In article <39CBC3DF.69A872F4@artquest.net>, Pierre Baillargeon
> > <pb@artquest.net> writes
> > >struct CMYK { char c, m, y, k };
> > >void foo ( )
> > >{
> > >   char * data = "hello";
> > >   CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> > >}
> > No, that comma is not an operator but just a punctuator. The above
code
> > has undefined behaviour.
>
> Sorry to ask again, but I have two different opinions from people I've
> learned to trust: you and Ron Natalie. Ron claims that each
initializer
> is in its own expression, so there is no undefined behavior.

The definition of "full expression" is given in 1.9p12: "an
expression that is not a subexpression of another expression."
As has been pointed out, an initializer-list (8.5p1) is not
an expression, so the assignment-expression in an
initializer-clause is a full expression.  There is a
sequence point after the evaluation of each full expression
(1.9p16), i.e., after each "data++" in the example.

Contrary to an earlier poster in this thread, this is NOT
like function arguments.  The order of evaluation of function
arguments is explicitly unspecified (5.2.2p8), but only
because function arguments are _subexpressions_ of the
function call expression (5p4).  There's no provision for
reordering the initializer-clauses in an initializer-list,
so (apart from the as-if rule) the initializations must be
done in declaration order, and the side effects of each
expression must be complete before the next one begins
(1.9p7).

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39CFB7AC.496CBAB8@artquest.net>, Pierre Baillargeon
<pb@artquest.net> writes
>Sorry to ask again, but I have two different opinions from people I've
>learned to trust: you and Ron Natalie. Ron claims that each initializer
>is in its own expression, so there is no undefined behavior.

Ron is right. An initialiser is a full expression and so terminates with
a sequence point. That means that there is no undefined behaviour,
however I am pretty sure that the order of evaluation is indeterminate,
but I would be happy to be corrected.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Ron Natalie" <ron@sensor.com> wrote in message
news:39CBC901.B20A0973@sensor.com...

> > struct CMYK { char c, m, y, k };
> > void foo ( )
> > {
> >    char * data = "hello";
> >    CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> > }
>
> Each one of these is it's own full expression and hence has a sequence
> point at the end of it.

I don't think so.

>From Standard 1.13
[ Note: certain context in C++ cause the evaluation of a full-expression
that results from a syntactic con-
struct other than expression(5.18). For example, in 8.5 one syntax for
initializer is

( expression-list )

but the resulting construct is a function call upon a constructor function
with expression-list as an argument
list; such a function call is a full-expression. For example, in 8.5,
another syntax for initializer is

= initializer-clause

but again the resulting construct might be a function call upon a
constructor function with one assignment-
expression as an argument; again, the function call is a full-expression]

-- Dag Henriksson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pierre Baillargeon wrote:
>
> Francis Glassborow wrote:
> >
> > In article <39CBC3DF.69A872F4@artquest.net>, Pierre Baillargeon
> > <pb@artquest.net> writes
> > >struct CMYK { char c, m, y, k };
> > >void foo ( )
> > >{
> > >   char * data = "hello";
> > >   CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> > >}
> > No, that comma is not an operator but just a punctuator. The above code
> > has undefined behaviour.
>
> Sorry to ask again, but I have two different opinions from people I've
> learned to trust: you and Ron Natalie. Ron claims that each initializer
> is in its own expression, so there is no undefined behavior

I've read the SPEC carefully (I always do when someone knowledgable contradicts
me, I want to make sure that I'm not wrong).  While there is some weaselness about
constructors and intializers with respect to expressions, I can't see how it makes
a difference here.

Of course the code construct is silly and probably ought to be avoided.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8qgm6j$fnm$1@bob.news.rcn.net>, Victor Bazarov
<vAbazarov@dAnai.com> writes
>It's not an expression.  It's an initialiser list.  As to legality, I
>suppose, it's legal, however, WHICH CMYK member will be initialised with
>WHAT, is impossible to determine.  I haven't found an appropriate quote
>from the Standard, but I would think that the same rule applies as to
>the function arguments -- the order of their evaluation is unknown.  If
>that is truly what the Standard says, then you must not rely on the
>order of evaluation when initialising aggregates.

No it is worse than that because data is modified four times between
sequence points. That means that the code has undefined behaviour.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39CBC3DF.69A872F4@artquest.net>, Pierre Baillargeon
<pb@artquest.net> writes
>struct CMYK { char c, m, y, k };
>void foo ( )
>{
>   char * data = "hello";
>   CMYK cmyk = { data++, data++, data++, data++ }; // legal?
>}
No, that comma is not an operator but just a punctuator. The above code
has undefined behaviour.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I know that using a comma in an expression produces a sequence point. I
was wondering what is the behavior in initialization of a structure.
That is, is the following code legal:

struct CMYK { char c, m, y, k };
void foo ( )
{
   char * data = "hello";
   CMYK cmyk = { data++, data++, data++, data++ }; // legal?
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Pierre Baillargeon" <pb@artquest.net> wrote...
> I know that using a comma in an expression produces a sequence point.
I
> was wondering what is the behavior in initialization of a structure.
> That is, is the following code legal:
>
> struct CMYK { char c, m, y, k };
                              ^^^
            Lost a semicolon there

> void foo ( )
> {
>    char * data = "hello";
>    CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> }

It's not an expression.  It's an initialiser list.  As to legality,
I suppose, it's legal, however, WHICH CMYK member will be initialised
with WHAT, is impossible to determine.  I haven't found an appropriate
quote from the Standard, but I would think that the same rule applies
as to the function arguments -- the order of their evaluation is
unknown.  If that is truly what the Standard says, then you must not
rely on the order of evaluation when initialising aggregates.

Victor
--
Please remove capital A's from my address when replying by mail



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pierre Baillargeon wrote:
>
> I know that using a comma in an expression produces a sequence point. I
> was wondering what is the behavior in initialization of a structure.
> That is, is the following code legal:
>
> struct CMYK { char c, m, y, k };
> void foo ( )
> {
>    char * data = "hello";
>    CMYK cmyk = { data++, data++, data++, data++ }; // legal?
> }

The comma here isn't the comma opeartor.  If it were the whole thing
would result in one value not four.

Each one of these is it's own full expression and hence has a sequence
point at the end of it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]