= Operator?

56 views
Skip to first unread message

Dr Mario

unread,
Mar 22, 2001, 2:13:55 AM3/22/01
to
I am reading an example program out of a book, and I have come across a
statement that involves two variables, and the constant 0:

m_nHScrollPos = m_nHPageSize = 0;

This statement has me confused, and I'm not not quite sure what it does.
is it setting both of the variables to 0 at once? If so, what is the order
of events? Is it: 1) m_nHPageSize gets set to 0, then m_nHScrollPos gets
set to m_nHPageSize (hence gettin 0)? Or is it this: 1) m_nHScrollPos gets
the value that is currently in m_nHPageSize, THEN 2) once that value has
been safely assigned to something else, m_nHPageSize gets 0? Please help
me, it is imperative that I know what this statement does. I have had quite
a bit of experience with the C++ language and never seen a statement like
this before. Thank you very much for your help, it is GREATLY appreciated
:-)

--Mario


Larry Brasfield

unread,
Mar 22, 2001, 2:29:13 AM3/22/01
to
On 3/21/2001, 11:13:55 PM, "Dr Mario"
<drm...@twcny.rr.com> wrote
regarding = Operator?:

> I am reading an example program out of a book, and I
> have come across a statement that involves two variables,
> and the constant 0:
>
> m_nHScrollPos = m_nHPageSize = 0;

> This statement has me confused, and I'm not not quite
> sure what it does. is it setting both of the variables to 0
> at once?

It sets both variables to 0 at some time
before the next statement is executed.

> If so, what is the order of events?

The order is not defined by the language.

...[snip]


> Please help
> me, it is imperative that I know what this statement does.

If you need to know more than I indicated above,
then you better not write such code.

> I have had quite a bit of experience with the C++ language
> and never seen a statement like this before.

For an experienced C++ programmer, you appear to have
led a very sheltered existence. That feature arose
in C decades ago.

-Larry Brasfield

Arthur H. Gold

unread,
Mar 22, 2001, 2:48:28 AM3/22/01
to
Larry Brasfield wrote:
>
> On 3/21/2001, 11:13:55 PM, "Dr Mario"
> <drm...@twcny.rr.com> wrote
> regarding = Operator?:
>
> > I am reading an example program out of a book, and I
> > have come across a statement that involves two variables,
> > and the constant 0:
> >
> > m_nHScrollPos = m_nHPageSize = 0;
>
> > This statement has me confused, and I'm not not quite
> > sure what it does. is it setting both of the variables to 0
> > at once?
>
> It sets both variables to 0 at some time
> before the next statement is executed.
>
> > If so, what is the order of events?
>
> The order is not defined by the language.
Sure it is.

a = b = 0;

is parsed as

a = (b = 0);

`b = 0' is a an expression that returns 0 (as well as having
the side effect of putting the value 0 into b), which is put
into `a'.

HTH,
--ag

--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:ag...@bga.com or mailto:ag...@cs.utexas.edu
--
Clone Bernie!

Clark S. Cox, III

unread,
Mar 22, 2001, 4:01:04 AM3/22/01
to
Arthur H. Gold <ag...@bga.com> wrote:

> Larry Brasfield wrote:
> >
> > On 3/21/2001, 11:13:55 PM, "Dr Mario"
> > <drm...@twcny.rr.com> wrote
> > regarding = Operator?:
> >
> > > I am reading an example program out of a book, and I
> > > have come across a statement that involves two variables,
> > > and the constant 0:
> > >
> > > m_nHScrollPos = m_nHPageSize = 0;
> >
> > > This statement has me confused, and I'm not not quite
> > > sure what it does. is it setting both of the variables to 0
> > > at once?
> >
> > It sets both variables to 0 at some time
> > before the next statement is executed.
> >
> > > If so, what is the order of events?
> >
> > The order is not defined by the language.
> Sure it is.
>
> a = b = 0;
>
> is parsed as
>
> a = (b = 0);
>
> `b = 0' is a an expression that returns 0 (as well as having
> the side effect of putting the value 0 into b), which is put
> into `a'.

No, the side effect of assignment can happen anytime before the next
sequence point, the assignment to a could very well happen before the
assignment to b. You are confusing precedenc with order of execution.


--
http://www.whereismyhead.com/clark/
Clark S. Cox, III
clar...@yahoo.com

Michael Kochetkov

unread,
Mar 22, 2001, 4:29:13 AM3/22/01
to
[...]

> > > The order is not defined by the language.
> > Sure it is.
> >
> > a = b = 0;
> >
> > is parsed as
> >
> > a = (b = 0);
> >
> > `b = 0' is a an expression that returns 0 (as well as having
> > the side effect of putting the value 0 into b), which is put
> > into `a'.
>
> No, the side effect of assignment can happen anytime before the next
> sequence point, the assignment to a could very well happen before the
> assignment to b. You are confusing precedenc with order of execution.
5.17/1 says that all assignment operators group right-to-left.
So, in the expression

a = b = 0;
b is assigned befor a.

With regards,
Michael Kochetkov.

Daniel Frey

unread,
Mar 22, 2001, 4:57:01 AM3/22/01
to

I'm not sure about that. IMHO it means that a is assigned the result of
the expression b = 0. If b is an integer, the compiler may think it
knows to result of that expression and therefore may transform it to
either

a = 0; b = 0;

or

b = 0; a = 0;

This helps the compiler to reduce dependencies and allows better
optimzations. Does it matter? Theoretically I think yes. Let's make a
complete example:

#include <iostream>
using namespace std;

int b = 42;

class A
{
private:
int i;

public:
A() {}
A& operator=( const int dummy ) { i = b; }
operator int() const { return i; }
};

int main()
{
A a;


a = b = 0;

cout << a << endl;
}

IMHO this example _probably_ outputs 0 (it did for me), but it could
output 42, couldn't it? Just curious...

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: danie...@aixigo.de, web: http://www.aixigo.de

Sai Shankar

unread,
Mar 22, 2001, 5:31:00 AM3/22/01
to

Dr Mario wrote:
>
> I am reading an example program out of a book, and I have come across a
> statement that involves two variables, and the constant 0:
>
> m_nHScrollPos = m_nHPageSize = 0;

m_nHScrollPos = (m_nHPageSize = 0);

m_nHPageSize is assigned the value 0 and the result of the assignment
expression (0) is assigned to m_nHScrollPos. It's just a fancy way of
writing:

m_nHPageSize = 0;
m_nHScrollPos = 0;

It's useful to use the first form when you need to remember to set
miultiple variables to the same value (during maintenance) always.

Hope this helps

Regards
Sai

Michael Kochetkov

unread,
Mar 22, 2001, 5:32:36 AM3/22/01
to

>"Daniel Frey" <danie...@aixigo.de> wrote in message
news:3AB9CC6D...@aixigo.de...
I doubt it. I still believe in 5.17/1.

>
>This helps the compiler to reduce dependencies and allows better
>optimzations. Does it matter? Theoretically I think yes. Let's make a
>complete example:
>
>#include <iostream>
>using namespace std;
>
>int b = 42;
>
>class A
>{
>private:
> int i;
>
>public:
> A() {}
> A& operator=( const int dummy ) { i = b; }
> operator int() const { return i; }
>};
>
>int main()
>{
> A a;
> a = b = 0;
> cout << a << endl;
>}
>
>IMHO this example _probably_ outputs 0 (it did for me), but it could
>output 42, couldn't it? Just curious...

It is bad example.


a = b = 0;

is equivalent to
a.operator=(b=0);
As far as all side effects of argument expression evaluations take affect
before the function is entered b will be assigned first. We have gotten the
same result but it is specified by the completely different rules. I wonder
if AT&T guys have done it on purpose or it was just a lucky chance?

With regards,
Michael Kochetkov.

Larry Brasfield

unread,
Mar 22, 2001, 5:38:55 AM3/22/01
to
On 3/22/2001, 1:29:13 AM, "Michael Kochetkov"
<Michael....@trustworks.commmm> wrote
regarding Re: = Operator?:

...
Larry Brasfield was indirectly quoted:


> > > > The order is not defined by the language.

to which Michael Kochetkov replied:


> > > Sure it is.
> > >
> > > a = b = 0;
> > >
> > > is parsed as
> > >
> > > a = (b = 0);
> > >
> > > `b = 0' is a an expression that returns 0 (as well as having
> > > the side effect of putting the value 0 into b), which is put
> > > into `a'.

As another poster informed you, that side effect
does not have a defined time of occurance other
than before the next sequence point. That point
is at the ';', which is "some time before the
next statement is executed", as I stated before.

Here, Clark S. Cox, III correctly corrected
Arthur H. Gold's assertion of the same mistake
being propagated by Michael Kochetkov:


> > No, the side effect of assignment can happen anytime before
> > the next sequence point, the assignment to a could very well
> > happen before the assignment to b. You are confusing precedenc
> > with order of execution.

> 5.17/1 says that all assignment operators group right-to-left.
> So, in the expression
> a = b = 0;
> b is assigned befor a.

Grouping, (or more commonly, association), does not
impose an ordering requirement upon the side effects
of an expression. Only sequence points do that. If
you are going to maintain otherwise, I urge you to
read the C++ standard carefully, concentrating on
the term "sequence point". I will assure you, in
advance, that you will not be able to contradict my
earlier statement regarding that double assignment,
"The order is not defined by the language.", with
any language from the C++ standard.

-Larry Brasfield

Larry Brasfield

unread,
Mar 22, 2001, 5:46:14 AM3/22/01
to
On 3/22/2001, 2:31:00 AM, Sai Shankar
<Sai.S...@blr.spcnl.co.in> wrote regarding
Re: = Operator?:

[earlier attributions cut]


> > m_nHScrollPos = m_nHPageSize = 0;
>
> m_nHScrollPos = (m_nHPageSize = 0);
>
> m_nHPageSize is assigned the value 0 and the result of the assignment
> expression (0) is assigned to m_nHScrollPos. It's just a fancy way of
> writing:
>
> m_nHPageSize = 0;
> m_nHScrollPos = 0;

Wrong. The assignments could happen, just as
correctly, so they occurred as if written:
m_nHScrollPos = 0;
m_nHPageSize = 0;

The difference, which goes beyond "fancy", is
that the two-statement version has a sequence
point between the assignments. If those names
refer to volatile objects, then the C++ standard
requires a particular order of writes to those
objects for the two-statement version while it
allows either order for the double assignment
expression.

-Larry Brasfield

Michael Kochetkov

unread,
Mar 22, 2001, 6:15:38 AM3/22/01
to
> "Larry Brasfield" <lbrasfie...@nospam.qwest.net> wrote in message
news:20010322...@mis.configured.host...
I do not urge you but if you are interested in this very compicated case I
will take a rist to recommend you to read 5.17/1 and Mr. Koenig's defect
report "222. Sequence points and lvalue-returning operators" (20 Dec 1999).
IMO the committee members prefer to think the way I do. But there is a
chance I misunderstood them.

With regards,
Michael Kochetkov.


Michael Kochetkov

unread,
Mar 22, 2001, 6:42:34 AM3/22/01
to
>
> "Larry Brasfield" <lbrasfie...@nospam.qwest.net> wrote in message
news:20010322...@mis.configured.host...
> On 3/22/2001, 1:29:13 AM, "Michael Kochetkov"
> <Michael....@trustworks.commmm> wrote
> regarding Re: = Operator?:
>
> ...
> Larry Brasfield was indirectly quoted:
> > > > > The order is not defined by the language.
> to which Michael Kochetkov replied:
> > > > Sure it is.
> > > >
> > > > a = b = 0;
> > > >
> > > > is parsed as
> > > >
> > > > a = (b = 0);
> > > >
> > > > `b = 0' is a an expression that returns 0 (as well as having
> > > > the side effect of putting the value 0 into b), which is put
> > > > into `a'.
Those are not my words

>
> As another poster informed you, that side effect
> does not have a defined time of occurance other
> than before the next sequence point. That point
> is at the ';', which is "some time before the
> next statement is executed", as I stated before.
>
> Here, Clark S. Cox, III correctly corrected
> Arthur H. Gold's assertion of the same mistake
> being propagated by Michael Kochetkov:
> > > No, the side effect of assignment can happen anytime before
> > > the next sequence point, the assignment to a could very well
> > > happen before the assignment to b. You are confusing precedenc
> > > with order of execution.
>


> 5.17/1 says that all assignment operators group right-to-left.
> So, in the expression
> a = b = 0;
> b is assigned befor a.

Those 4 lines are the only of mine.

To the OP. Here is the exact quote from 5.17/1:
"There are several assignment operators, all of which group right-to-left.
All require a modifiable lvalue as their left operand, and the type of an
assignment expression is that of its left operand. The result of the
assignment operation is the value stored in the left operand after the
assignment has taken place; the result is an lvalue."

The problem words (at least for me) are "after the assignment has taken
place". But befor one starts to comment them, please, read the DR I have
pointed out earlier ("222. Sequence points and lvalue-returning operators"
(20 Dec 1999).

With regards,
Michael Kochetkov.

Clark S. Cox, III

unread,
Mar 22, 2001, 8:43:35 AM3/22/01
to
Michael Kochetkov <Michael....@trustworks.commmm> wrote:

> [...]
> > > > The order is not defined by the language.
> > > Sure it is.
> > >
> > > a = b = 0;
> > >
> > > is parsed as
> > >
> > > a = (b = 0);
> > >
> > > `b = 0' is a an expression that returns 0 (as well as having
> > > the side effect of putting the value 0 into b), which is put
> > > into `a'.
> >
> > No, the side effect of assignment can happen anytime before the next
> > sequence point, the assignment to a could very well happen before the
> > assignment to b. You are confusing precedenc with order of execution.
> 5.17/1 says that all assignment operators group right-to-left.

This "grouping" determines precedence, not order of execution. The
assignments can happen in any order, as long as they occur before the
next sequence point. The grouping does, however, ensure that the
following two expressions are equivelant:

a = b = 0;

a = (b = 0);

However, in both statements, the assignment to a can very well


happen before the assignment to b.

> So, in the expression


> a = b = 0;
> b is assigned befor a.

No

Dan Cernat

unread,
Mar 22, 2001, 10:32:01 AM3/22/01
to

"Michael Kochetkov" <Michael....@trustworks.commmm> wrote in message
news:3ab9...@news.telekom.ru...

It is not a bad example at all. it will always output 0.

Dan


Michael Kochetkov

unread,
Mar 22, 2001, 3:55:31 AM3/22/01
to

"Larry Brasfield" <lbrasfie...@nospam.qwest.net> wrote in message
news:20010322...@mis.configured.host...
On 3/21/2001, 11:13:55 PM, "Dr Mario"
<drm...@twcny.rr.com> wrote
regarding = Operator?:

> > I am reading an example program out of a book, and I
> > have come across a statement that involves two variables,
> > and the constant 0:
> >
> > m_nHScrollPos = m_nHPageSize = 0;

> > This statement has me confused, and I'm not not quite
> > sure what it does. is it setting both of the variables to 0
> > at once?

> It sets both variables to 0 at some time
> before the next statement is executed.

It is true for fundumental types. But we are in the C++ group, do not we?
For user defined types it would be equivalent to:
m_nHScrollPos.operator = (m_nHPageSize.operator = (0));

> > If so, what is the order of events?

> The order is not defined by the language.

It does defined and the order is very important. All assignment operators
group right-to-left.

With regards,
Michael Kochetkov.

Ray Fischer

unread,
Mar 22, 2001, 5:00:52 PM3/22/01
to
Clark S. Cox, III <clar...@yahoo.com> wrote:
>Michael Kochetkov <Michael....@trustworks.commmm> wrote:

>> > No, the side effect of assignment can happen anytime before the next
>> > sequence point, the assignment to a could very well happen before the
>> > assignment to b. You are confusing precedenc with order of execution.
>> 5.17/1 says that all assignment operators group right-to-left.
>
> This "grouping" determines precedence, not order of execution.

Must be a new meaning of the word "precedence" that I was previously
unaware of. Last I knew, something with higher precedence got done
before something with lower precedence.

> The
>assignments can happen in any order, as long as they occur before the
>next sequence point. The grouping does, however, ensure that the
>following two expressions are equivelant:
>
>a = b = 0;
>a = (b = 0);
>
> However, in both statements, the assignment to a can very well
>happen before the assignment to b.

While it is true that instruction scheduling in both the compiler and
in the CPU can affect the actual order of execution, real-world
contraints makes such triviality nearly meaningless.

>> So, in the expression
>> a = b = 0;
>> b is assigned befor a.
>
> No

quibble:
1. To evade the truth or importance of an issue by raising trivial
distinctions and objections.
2. To find fault or criticize for petty reasons; cavil.


--
Ray Fischer When you look long into an abyss, the abyss also looks
rfis...@sonic.net into you -- Nietzsche

Victor Bazarov

unread,
Mar 22, 2001, 5:13:59 PM3/22/01
to
"Ray Fischer" <rfis...@sonic.net> wrote...

> Clark S. Cox, III <clar...@yahoo.com> wrote:
> >Michael Kochetkov <Michael....@trustworks.commmm> wrote:
>
> >> > No, the side effect of assignment can happen anytime before
the next
> >> > sequence point, the assignment to a could very well happen before
the
> >> > assignment to b. You are confusing precedenc with order of
execution.
> >> 5.17/1 says that all assignment operators group right-to-left.
> >
> > This "grouping" determines precedence, not order of execution.
>
> Must be a new meaning of the word "precedence" that I was previously
> unaware of. Last I knew, something with higher precedence got done
> before something with lower precedence.

You're definitely confused.

The language cannot guarantee that in the expression

a = b+c | d->e

the (d->e) will be executed _BEFORE_ (b+c) (although it has a higher
precedence). Only that the result will be the same as

t1 = d->e
t2 = b+c
a = t2 | t1

considering that there are NO sequence points between the assignments.

The order is NOT determined by precedence. It's given to the language
implementation to decide (provided that other requirements of the
Standard are met).

>
> > The
> >assignments can happen in any order, as long as they occur before the
> >next sequence point. The grouping does, however, ensure that the
> >following two expressions are equivelant:
> >
> >a = b = 0;
> >a = (b = 0);
> >
> > However, in both statements, the assignment to a can very well
> >happen before the assignment to b.
>
> While it is true that instruction scheduling in both the compiler and
> in the CPU can affect the actual order of execution, real-world
> contraints makes such triviality nearly meaningless.

What are you talking about?

>
> >> So, in the expression
> >> a = b = 0;
> >> b is assigned befor a.
> >
> > No
>
> quibble:
> 1. To evade the truth or importance of an issue by raising trivial
> distinctions and objections.
> 2. To find fault or criticize for petty reasons; cavil.

The reason some postings are made is to correct a mistake made by
another poster. It often may not be relevant to the original
question or issue. Complaining about such practice is foolish.

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

Clark S. Cox, III

unread,
Mar 22, 2001, 5:15:19 PM3/22/01
to
Ray Fischer <rfis...@sonic.net> wrote:

> Clark S. Cox, III <clar...@yahoo.com> wrote:
> >Michael Kochetkov <Michael....@trustworks.commmm> wrote:
>
> >> > No, the side effect of assignment can happen anytime before the next
> >> > sequence point, the assignment to a could very well happen before the
> >> > assignment to b. You are confusing precedenc with order of execution.
> >> 5.17/1 says that all assignment operators group right-to-left.
> >
> > This "grouping" determines precedence, not order of execution.
>
> Must be a new meaning of the word "precedence" that I was previously
> unaware of. Last I knew, something with higher precedence got done
> before something with lower precedence.

No, in C and C++, assignments can happen at anytime, and in any
order before the next sequence-point.

> > The
> >assignments can happen in any order, as long as they occur before the
> >next sequence point. The grouping does, however, ensure that the
> >following two expressions are equivelant:
> >
> >a = b = 0;
> >a = (b = 0);
> >
> > However, in both statements, the assignment to a can very well
> >happen before the assignment to b.
>
> While it is true that instruction scheduling in both the compiler and
> in the CPU can affect the actual order of execution, real-world
> contraints makes such triviality nearly meaningless.

It's not meaningless, it's explicitly allowed by the standard.


--
http://www.whereismyhead.com/clark/

Don Perkins

unread,
Mar 22, 2001, 5:21:16 PM3/22/01
to
*** post for FREE via your newsreader at post.newsfeeds.com ***

Larry Brasfield wrote:

> On 3/22/2001, 2:31:00 AM, Sai Shankar

> <Sai.S...@blr.spcnl.co.in> wrote regarding
> Re: = Operator?:
>
> [earlier attributions cut]


> > > m_nHScrollPos = m_nHPageSize = 0;
> >

> > m_nHScrollPos = (m_nHPageSize = 0);
> >
> > m_nHPageSize is assigned the value 0 and the result of the
assignment
> > expression (0) is assigned to m_nHScrollPos. It's just a fancy way
of
> > writing:
> >
> > m_nHPageSize = 0;
> > m_nHScrollPos = 0;
>
> Wrong. The assignments could happen, just as
> correctly, so they occurred as if written:
> m_nHScrollPos = 0;
> m_nHPageSize = 0;
>
> The difference, which goes beyond "fancy", is
> that the two-statement version has a sequence
> point between the assignments. If those names
> refer to volatile objects, then the C++ standard
> requires a particular order of writes to those
> objects for the two-statement version while it
> allows either order for the double assignment
> expression.
>
> -Larry Brasfield

Sorry, Larry. If folks are finding the standard ambiguous, may I quote
two
*members* of the ISO/IEC C++ Standard Committee on the intent of
right-to-left operator precedence for the assignment operator?

========
Per Herbert Schildt "C++: The Complete Reference, 3rd Ed.", Osbborne
Press
1998, p. 36 --

"Multiple Assignments

C/C++ allows you to assign many variables the same value by using
multiple
assignments in a single statement. For example, this program fragment
assigns x, y,[sic] and z the value 0:

x = y = z = 0;"

========
Per C++ language creator, Bjarne Stroustrup in "The C++ Programming
Language, Special Edition", Addison-Wesley 2000, p. 121 (Section 6.2 -
Operator Summary) --

"Unary operators and assignment operators are right-associative; all
others
are left-associative. For example, a=b=c means a=(b+c), a+b+c means
(a+b)+c."

========
Associativity is a mathematical concept which defines *order of
operation*.
Unless both Stroustrup and Schildt are wrong (and I'll be the first to
admit
that the latter has made egregious mistakes in print) the *intent* of
the
Standard is that the assignment operator has right-associative
*execution* precedence.

By the by, this is an ANCIENT "C " concept, and most any book on C or
C++ will mention, albeit briefly, the right-associative properties of
the
assignment operator. (This behavior is also found in PL/1, and if
memory
serves me right, in "modern" dialects of FORTRAN.)

The practice of multiple assignment and its dependence on
right-associativity is so prevalent in existing C (and possibly to a
lesser
extent, C++) code, that any language vendor not enforcing a right-most
execution order would certainly render a huge volume of code as buggy
and
full of unitialized values.

The execution order of the assignment operator is *not* implementation
dependent: It gives precedence to the right-most expression.

--
Don Perkins
Software Engineer III
Applied Signal Technology, Inc.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 90,000 Newsgroups - 16 Different Servers! =-----

Ray Fischer

unread,
Mar 22, 2001, 5:26:21 PM3/22/01
to
Clark S. Cox, III <clar...@yahoo.com> wrote:
>Ray Fischer <rfis...@sonic.net> wrote:
>> Clark S. Cox, III <clar...@yahoo.com> wrote:
>> >Michael Kochetkov <Michael....@trustworks.commmm> wrote:

>> >> > No, the side effect of assignment can happen anytime before the next
>> >> > sequence point, the assignment to a could very well happen before the
>> >> > assignment to b. You are confusing precedenc with order of execution.
>> >> 5.17/1 says that all assignment operators group right-to-left.
>> >
>> > This "grouping" determines precedence, not order of execution.
>>
>> Must be a new meaning of the word "precedence" that I was previously
>> unaware of. Last I knew, something with higher precedence got done
>> before something with lower precedence.
>
> No, in C and C++, assignments can happen at anytime, and in any
>order before the next sequence-point.

Can? Yes. Will? Probably not. Is that at all relevant to the
neophyte programmer who posed the question? No.

>> > The
>> >assignments can happen in any order, as long as they occur before the
>> >next sequence point. The grouping does, however, ensure that the
>> >following two expressions are equivelant:
>> >
>> >a = b = 0;
>> >a = (b = 0);
>> >
>> > However, in both statements, the assignment to a can very well
>> >happen before the assignment to b.
>>
>> While it is true that instruction scheduling in both the compiler and
>> in the CPU can affect the actual order of execution, real-world
>> contraints makes such triviality nearly meaningless.
>
> It's not meaningless, it's explicitly allowed by the standard.

Read what I wrote. About the only time such details are of any
relevance is when 1) You are writing the compiler, and 2) You're
depending upon exact order because of external hardware-related
issues.

Personally, I consider the a=b=0 construct to be sloppy programming
precisely because it so easily masks what's really happening. In C++
a=b=0 and b=0;a=0 can have completely different results. But
there are better things to do than dump obscure arcana upon innocent
neophytes.

Clark S. Cox, III

unread,
Mar 22, 2001, 5:28:19 PM3/22/01
to
Don Perkins <don_p...@appsig.com> wrote:

Never listen to anything that Schildt says, plain and simple.

>
> ========
> Per C++ language creator, Bjarne Stroustrup in "The C++ Programming
> Language, Special Edition", Addison-Wesley 2000, p. 121 (Section 6.2 -
> Operator Summary) --
>
> "Unary operators and assignment operators are right-associative; all
> others
> are left-associative. For example, a=b=c means a=(b+c), a+b+c means
> (a+b)+c."

But he says nothing about the *order of execution*!


>
> ========
> Associativity is a mathematical concept which defines *order of
> operation*.
> Unless both Stroustrup and Schildt are wrong (and I'll be the first to
> admit
> that the latter has made egregious mistakes in print) the *intent* of
> the
> Standard is that the assignment operator has right-associative
> *execution* precedence.
>
> By the by, this is an ANCIENT "C " concept, and most any book on C or
> C++ will mention, albeit briefly, the right-associative properties of
> the
> assignment operator. (This behavior is also found in PL/1, and if
> memory
> serves me right, in "modern" dialects of FORTRAN.)
>
> The practice of multiple assignment and its dependence on
> right-associativity is so prevalent in existing C (and possibly to a
> lesser
> extent, C++) code, that any language vendor not enforcing a right-most
> execution order would certainly render a huge volume of code as buggy
> and
> full of unitialized values.
>
> The execution order of the assignment operator is *not* implementation
> dependent: It gives precedence to the right-most expression.

That is simply wrong. The order is only defined if there is an
intervening sequence point, which isn't the case for simple types.


--
http://www.whereismyhead.com/clark/

Victor Bazarov

unread,
Mar 22, 2001, 5:40:06 PM3/22/01
to
"Don Perkins" <don_p...@appsig.com> wrote...

Yes, yes! But in UNSPECIFIED ORDER.

>
> ========
> Per C++ language creator, Bjarne Stroustrup in "The C++ Programming
> Language, Special Edition", Addison-Wesley 2000, p. 121 (Section 6.2 -
> Operator Summary) --
>
> "Unary operators and assignment operators are right-associative; all
> others
> are left-associative. For example, a=b=c means a=(b+c), a+b+c means

^^^^^^^^
a=(b=c)

Precedence, yes. Order of execution, no.

What Larry was saying was that the assignment of the right-most
expression to each of the left-hand expressions can happen in
any order. It does NOT mean that the assignment is right-associated.

Unless the assignment operator is A FUNCTION defined for the types
involved, there is NO SEQUENCE POINT after it.

If
int a, b, c = 1;
a = b = c;
the second STATEMENT can be executed either as
a = c;
b = c;
or as
b = c;
a = c;
or as
b = c;
a = b;
in regard of physically changing the values of the OBJECTS 'a' and 'b'
(that is the memory where they reside).

Don Perkins

unread,
Mar 22, 2001, 5:52:25 PM3/22/01
to
*** post for FREE via your newsreader at post.newsfeeds.com ***

"Clark S. Cox, III" wrote:

> Don Perkins <don_p...@appsig.com> wrote:
>
> > Per C++ language creator, Bjarne Stroustrup in "The C++ Programming
> > Language, Special Edition", Addison-Wesley 2000, p. 121 (Section 6.2
> -
> > Operator Summary) --
> >
> > "Unary operators and assignment operators are right-associative; all
>
> > others
> > are left-associative. For example, a=b=c means a=(b+c), a+b+c means
>

> > (a+b)+c."
>
> But he says nothing about the *order of execution*!

WHAT!?!?!?!?

First off, I appologize for a typing error. The example should read
"... For example, a=b=c means a=(b=c)..."

THIS WITHOUT A DOUBT SAYS THAT b=c MUST BE EVALUATED before any
assignment is made to a. If not, then parentheses in mathematical
expressions have no meaning. Stroustrup's intent by the above
statement was to convey the mathematical interpretation to be applied.
That interpretation guides the requirements of execution. The rightmost
assignment will be made first. Period.


Per Stroustrup, the evaluation order is right to left
FOR THE EQUIVALENCE OPERATOR. Evaluation order for other oprations can
be implemntation (or even optimization-level) dependent. Section 5/4
begins with the words "Except where noted..." Section 5.17/1 makes such
a notation, to my understanding.

Neil Butterworth

unread,
Mar 22, 2001, 6:06:22 PM3/22/01
to
"Ray Fischer" <rfis...@sonic.net> wrote in message
news:99dslt$j...@bolt.sonic.net...

> Clark S. Cox, III <clar...@yahoo.com> wrote:
> >Michael Kochetkov <Michael....@trustworks.commmm> wrote:
>
> >> > No, the side effect of assignment can happen anytime before the
next
> >> > sequence point, the assignment to a could very well happen before the
> >> > assignment to b. You are confusing precedenc with order of execution.
> >> 5.17/1 says that all assignment operators group right-to-left.
> >
> > This "grouping" determines precedence, not order of execution.
>
> Must be a new meaning of the word "precedence" that I was previously
> unaware of. Last I knew, something with higher precedence got done
> before something with lower precedence.

Then you don't know very much. Consider the expression:

a - b* c;

C++ (and C) precedence rules have nothing to say about the order of
evaluation of the variables a,b and c. They do however say that once these
variables have been evaluated, the value of the complete expression must
(after evaluation) be

a - (b * c);

NeilB

Don Perkins

unread,
Mar 22, 2001, 6:12:07 PM3/22/01
to
*** post for FREE via your newsreader at post.newsfeeds.com ***

Victor Bazarov wrote:Precedence, yes. Order of execution, no.

> What Larry was saying was that the assignment of the right-most
> expression to each of the left-hand expressions can happen in
> any order. It does NOT mean that the assignment is right-associated.
>
> Unless the assignment operator is A FUNCTION defined for the types
> involved, there is NO SEQUENCE POINT after it.
>
> If
> int a, b, c = 1;
> a = b = c;
> the second STATEMENT can be executed either as
> a = c;
> b = c;
> or as
> b = c;
> a = c;
> or as
> b = c;
> a = b;
> in regard of physically changing the values of the OBJECTS 'a' and 'b'
>
> (that is the memory where they reside).

If this is truly what Larry and Clark are referring to, then we are
arguing at crossed-purposes. The important concept for the OP is that
the EFFECT of an assignment in the form "a=b=c" should be interpreted as
"a=(b=c)". That is what he was asking about. He had never seen a case
of multiple assignment before and was worried about the possibility that
this was a "rolling" assignment of the form: "a=b; b=c;"

Whether the implementation chooses to use "b=c; a=b;" or "a=c; b=c;" or
even "b=c; a=c;" is inconsequential unless you are using
register/hardware tied variables and the actual order of assignments is
critical. (In which case, using a multiple assignment is pure
foolishness. Implementations change...)

What *IS* consequential, and what I believe began this debate, is the
assertion that "a=b; b=c;" is a valid interpretation of "a=b=c" under
the Standard. This is tacitly not the case. As I said earlier, there
is a great deal of code that depends on the well-established
interpretation of multiple assignment and that the EFFECT is a
right-to-left reading.

As to whether or not this is a "good" coding practice... I'll leave that
to others to hash about. ;-)

Victor Bazarov

unread,
Mar 22, 2001, 6:23:34 PM3/22/01
to
"Don Perkins" <don_p...@appsig.com> wrote...

Well, you keep using such terminology as "order of execution" or
"order of operation", "order of evaluation" freely interchanging
them without care. That alone brings a lot of confusion.

Assignments are associated right-to-left. That determines WHAT is
assigned to the left-most, not WHEN it's done. An assignment is
initiated at a particular point, but it doesn't have to be complete
before the next assignment is initiated. Any assignment has a side
effect: it changes the value of the object on the left side. The
_side_effect_ doesn't have to appear until the next sequence point.

That's all. Nobody argued left-to-right associativity. We seem
to be in violent agreement here.

Pete Becker

unread,
Mar 22, 2001, 6:34:22 PM3/22/01
to
Don Perkins wrote:
>
> "Clark S. Cox, III" wrote:
>
> > Don Perkins <don_p...@appsig.com> wrote:
> >
> > > Per C++ language creator, Bjarne Stroustrup in "The C++ Programming
> > > Language, Special Edition", Addison-Wesley 2000, p. 121 (Section 6.2
> > -
> > > Operator Summary) --
> > >
> > > "Unary operators and assignment operators are right-associative; all
> >
> > > others
> > > are left-associative. For example, a=b=c means a=(b+c), a+b+c means
> >
> > > (a+b)+c."
> >
> > But he says nothing about the *order of execution*!
>
> WHAT!?!?!?!?
>
> First off, I appologize for a typing error. The example should read
> "... For example, a=b=c means a=(b=c)..."
>
> THIS WITHOUT A DOUBT SAYS THAT b=c MUST BE EVALUATED before any
> assignment is made to a. If not, then parentheses in mathematical
> expressions have no meaning. Stroustrup's intent by the above
> statement was to convey the mathematical interpretation to be applied.

I doubt very much that that was his intent, because that is wrong. This
is not a mathematical expression; it is a description of the effects of
a particular construct in the C and C++ programming languages.

> That interpretation guides the requirements of execution. The rightmost
> assignment will be made first. Period.
>
> Per Stroustrup, the evaluation order is right to left
> FOR THE EQUIVALENCE OPERATOR. Evaluation order for other oprations can
> be implemntation (or even optimization-level) dependent. Section 5/4
> begins with the words "Except where noted..." Section 5.17/1 makes such
> a notation, to my understanding.
>

No. 5.17/1 talks about grouping, not about order of evaluation. Grouping
is about what an expression means. Order of evaluation is about how to
evaluate it. In C and C++ they are two separate topics. In order for the
expression a=b=c to make sense, = must group right to left. That is, it
means assign the value of c to b, and assign the value of that assigment
expression to a. The value of that assigment expression is c. If =
grouped left to right this expression simply wouldn't make sense.

In terms of order of evaluation, however, the expression says nothing
about whether b or a gets its value written first. The value of 'b=c' is
c, and the compiler is free to copy the value of c into a, then to copy
the value of c into b. Requiring the assignments to take place in a
particular order (as in Java) eliminates optimization opportunities that
the compiler could otherwise take advantage of. C and C++ try pretty
hard to stay out of the way of optimizers. That's why so much behavior
is unspecified.

Contrast this with the wording, for example, of 5.15/1:

The || operator groups left-to-right. The operands are both implicitly
converted to bool (clause 4). It
returns true if either of its operands is true, and false otherwise.
Unlike |, || guarantees left-to-right
evaluation; moreover, the second operand is not evaluated if the first
operand evaluates to true.

Now, if left-to-right grouping specified order of evaluation, then the
third sentence, about the order of evaluation, would not be necessary.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker

unread,
Mar 22, 2001, 6:41:43 PM3/22/01
to

"Right-to-left" is a term used to describe grouping, not precedence.

>
> ========
> Per Herbert Schildt "C++: The Complete Reference, 3rd Ed.", Osbborne
> Press
> 1998, p. 36 --
>
> "Multiple Assignments
>
> C/C++ allows you to assign many variables the same value by using
> multiple
> assignments in a single statement. For example, this program fragment
> assigns x, y,[sic] and z the value 0:
>
> x = y = z = 0;"
>

This says nothing at all that supports the claim that the order of the
assignments is specified. Now you can quote another *member* of the
ISO/IEC C++ Standards Committee (and one who participated far more than
Herb Schildt): the order of the assignments to these variables is
unspecified.

Pete Becker

unread,
Mar 22, 2001, 6:52:01 PM3/22/01
to
Victor Bazarov wrote:
>
> Well, you keep using such terminology as "order of execution" or
> "order of operation", "order of evaluation" freely interchanging
> them without care. That alone brings a lot of confusion.
>
> Assignments are associated right-to-left. That determines WHAT is
> assigned to the left-most, not WHEN it's done. An assignment is
> initiated at a particular point, but it doesn't have to be complete
> before the next assignment is initiated. Any assignment has a side
> effect: it changes the value of the object on the left side. The
> _side_effect_ doesn't have to appear until the next sequence point.
>

To underscore what Victor said: although it isn't particularly
significant in this example, muddling order of evaluation and
associativity will get you in trouble eventually. Think about the
following code:

int i = 0;

int f()
{
++i;
return i;
}

void g()
{
++i;
return i;
}

std::cout << f() << ' ' << g() << '\n';

The output can be

1 2

or

2 1

Both are legal.

Don Perkins

unread,
Mar 22, 2001, 6:50:18 PM3/22/01
to
*** post for FREE via your newsreader at post.newsfeeds.com ***

> Well, you keep using such terminology as "order of execution" or


> "order of operation", "order of evaluation" freely interchanging
> them without care. That alone brings a lot of confusion.
>

Actually, I only used "order of execution". A giant _mea culpa_ to all
concerned. My concern here was on behalf of the OP and all of my
responses were in the light of serving *his* question. I should have
used the phrase "effective order of execution". My apologies to all for
not realizing that y'all were not aguing for a non right-to-left
effective result, but for the internal operations of the generated
object code -- and for some seriously imprecise speech.

> Assignments are associated right-to-left. That determines WHAT is
> assigned to the left-most, not WHEN it's done. An assignment is
> initiated at a particular point, but it doesn't have to be complete
> before the next assignment is initiated. Any assignment has a side
> effect: it changes the value of the object on the left side. The
> _side_effect_ doesn't have to appear until the next sequence point.
>

Agreed -- now that we are talking from the same reference point.

> That's all. Nobody argued left-to-right associativity.

No, but the appearance in light of what the OP wanted to know seemed to
leave that issue up in the air. The OP stated he had never seen a
multiple assignment construct and was seriously confused by it. He
asked about the "order of events". The context of that question was
"what is the EFFECTIVE order of events", a question that I answered.
Clark's answer went directly to the underlying implementation. I was in
"help the confused" mode and failed to see that Clark's focus was on the
implementation, not on clarifying the precedence question. The
OP wanted to know about precedence, not executional arcana. (This was
verified in a rather exuberant thank you note from the OP sent to my
private email.)

> We seem
> to be in violent agreement here.
>

Concurring vehemently...

Larry Brasfield

unread,
Mar 22, 2001, 8:37:44 PM3/22/01
to
This thread involves the order of writes dictated
by an expression of the form: i = j = 0;

(Article also posted to comp.lang.c++.moderated
and followups set to there only.)

"Don Perkins" <don_p...@appsig.com>
wrote in message news:<3ABA7ADC...@appsig.com>...
[Spam cut.]


> Larry Brasfield wrote:
>
> > On 3/22/2001, 2:31:00 AM, Sai Shankar
> > <Sai.S...@blr.spcnl.co.in> wrote

....


> > > > m_nHScrollPos = m_nHPageSize = 0;
> > >
> > > m_nHScrollPos = (m_nHPageSize = 0);
> > >
> > > m_nHPageSize is assigned the value 0 and the result
> > > of the assignment expression (0) is assigned to
> > > m_nHScrollPos. It's just a fancy way of writing:
> > >
> > > m_nHPageSize = 0;
> > > m_nHScrollPos = 0;
> >
> > Wrong. The assignments could happen, just as
> > correctly, so they occurred as if written:
> > m_nHScrollPos = 0;
> > m_nHPageSize = 0;
> >
> > The difference, which goes beyond "fancy", is
> > that the two-statement version has a sequence
> > point between the assignments. If those names
> > refer to volatile objects, then the C++ standard
> > requires a particular order of writes to those
> > objects for the two-statement version while it
> > allows either order for the double assignment
> > expression.

....


> Sorry, Larry. If folks are finding the standard ambiguous,
> may I quote two *members* of the ISO/IEC C++ Standard
> Committee on the intent of right-to-left operator precedence
> for the assignment operator?

You may quote, of course. But your quotes
do not actually address the controversy.

> ========
> Per Herbert Schildt "C++: The Complete Reference, 3rd Ed.",
> Osbborne Press 1998, p. 36 --
>
> "Multiple Assignments
>
> C/C++ allows you to assign many variables the same value by
> using multiple assignments in a single statement. For example,
> this program fragment assigns x, y,[sic] and z the value 0:
>
> x = y = z = 0;"

Do you see anything about the order in which those
3 objects are supposed to be written? I cannot.
(Besides, I will personally vouch for the notion
that Herbert Schildt is an unreliable authority,
to the point of being no authority at all.)

> ========
> Per C++ language creator, Bjarne Stroustrup in "The C++
> Programming Language, Special Edition", Addison-Wesley 2000,
> p. 121 (Section 6.2 - Operator Summary) --
>
> "Unary operators and assignment operators are right-associative;
> all others are left-associative. For example, a=b=c means
> a=(b+c), a+b+c means (a+b)+c."
> ========

Again, nothing about order of writes appears.

> Associativity is a mathematical concept which defines
> *order of operation*.

I never learned it that way in my math courses. I
always thought it related only to binding. If you
could cite the mathematical authority that dictates
how evaluation order is related to association, and
then explain how the C++ standard defers to such an
authority or rule, I may yet eat crow. But in my
reading of the standard, I've seen nothing that
controverts my position that the order of writes
for a = b = 0; is uncontrolled by the C++ standard.

> Unless both Stroustrup and Schildt are wrong (and
> I'll be the first to admit that the latter has made
> egregious mistakes in print) the *intent* of the
> Standard is that the assignment operator has right-
> associative *execution* precedence.

I see no such intent. In fact, I see the intent of
all the language about sequence points to be active
avoidance of over-specifying details such as this.

> By the by, this is an ANCIENT "C " concept, and
> most any book on C or C++ will mention, albeit
> briefly, the right-associative properties of the
> assignment operator. (This behavior is also found
> in PL/1, and if memory serves me right, in "modern"
> dialects of FORTRAN.)

Nobody is arguing about the associativity rules.

> The practice of multiple assignment and its dependence
> on right-associativity is so prevalent in existing C
> (and possibly to a lesser extent, C++) code, that any
> language vendor not enforcing a right-most execution
> order would certainly render a huge volume of code as
> buggy and full of unitialized values.

I doubt very much that this ordering has the consequences
that you surmise. It would only matter in an improperly
synchronized multi-thread scenario or where the targets
of the assignment(s) were hardware registers. I doubt
device driver writers depend on the rule you expound.

> The execution order of the assignment operator is *not*
> implementation dependent: It gives precedence to the
> right-most expression.

Nope. Precedence need not determine execution order.

[Signature and more Spam cut.]

-Larry Brasfield
Above opinions are my own.
(address munged against Spam)

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

Jack Klein

unread,
Mar 23, 2001, 12:08:07 AM3/23/01
to
On Thu, 22 Mar 2001 12:29:13 +0300, "Michael Kochetkov"
<Michael....@trustworks.commmm> wrote in comp.lang.c++:

> [...]


> > > > The order is not defined by the language.

> > > Sure it is.


> > >
> > > a = b = 0;
> > >

> > > is parsed as


> > >
> > > a = (b = 0);
> > >

> > > `b = 0' is a an expression that returns 0 (as well as having
> > > the side effect of putting the value 0 into b), which is put
> > > into `a'.
> >

> > No, the side effect of assignment can happen anytime before the next
> > sequence point, the assignment to a could very well happen before the
> > assignment to b. You are confusing precedenc with order of execution.
> 5.17/1 says that all assignment operators group right-to-left.

> So, in the expression


> a = b = 0;

> b is assigned befor a.
>

> With regards,
> Michael Kochetkov.

There is _NEVER_ any guarantee as to when assignments are actually
performed in between sequence points, other than that they all happen
by the sequence point.

Consider:

double d = 3.14159;
double e;
int i;

e = i = d;

The associativity means that e will be assigned the value 3.0, not
3.14159. It does not mean that this will happen after the value 3 is
assigned to i.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

Larry Brasfield

unread,
Mar 23, 2001, 5:46:56 AM3/23/01
to
On 3/22/2001, 3:50:18 PM, Don Perkins
<don_p...@appsig.com> wrote
regarding Re: = Operator?:

>
[Material quoted with '> >' should be attributed to Victor Bazarov.]


> > Well, you keep using such terminology as "order of execution" or
> > "order of operation", "order of evaluation" freely interchanging
> > them without care. That alone brings a lot of confusion.
> >
> Actually, I only used "order of execution".

Earlier, you wrote: "The rightmost assignment will be made
first. Period." In a post prior to that on this thread,
giving every appearance of contradicting my assertion,


If those names refer to volatile objects, then the C++
standard requires a particular order of writes to those
objects for the two-statement version while it allows
either order for the double assignment expression.

you responded, "Sorry, Larry." and quoted some stuff
which you contend(ed) "defines *order of operation*."
You went on to divine "the *intent* of the Standard",
whereby "the assignment operator has right-associative
*execution* precedence."

So, Victor is right. You have (*actually*) used plenty
of different terminology relating to the order in which
operation/evaluation/execution occurs. I don't see why
you see fit to contradict him on such a verifiable point.

> A giant _mea culpa_ to all concerned.
> My concern here was on behalf of the OP and all of my
> responses were in the light of serving *his* question.

What, specifically, did you find inadequate about my
initial response to the OP? That was where I stated:


It sets both variables to 0 at some time
before the next statement is executed.

and, as to "the order of events" (OP's phrase):


The order is not defined by the language.

Have you actually added any correct information, which
answers the OP's questions, that I did not provide?
Is there something confusing about my formulation?

> I should have
> used the phrase "effective order of execution".

I fail to see how "effective" could clarify anything.

...


> > That's all. Nobody argued left-to-right associativity.
>
> No, but the appearance in light of what the OP wanted to
> know seemed to leave that issue up in the air.

My initial response certainly covered that possibility.
Clark's responses also clearly disposed of that issue.

> The OP stated he had never seen a multiple assignment
> construct and was seriously confused by it. He asked
> about the "order of events". The context of that
> question was "what is the EFFECTIVE order of events",
> a question that I answered.

Let's look at what the OP actually asked:


is it setting both of the variables to 0 at once?

If so, what is the order of events?

This concern with ordering is not to resolve what
effect the expression has -- that is presupposed in
the OP's question. The OP's question about order
is _in addition_ to the question about _effect_.

> Clark's answer went directly to the underlying implementation.
> I was in "help the confused" mode and failed to see that Clark's

> focus was on the implementation, ...

Clark's contributions have been uniformly correct and
to the point in this thread. He has not focused on
the implementation so much as on what can and cannot
be assumed true, given the language requirements.
For example, early on, he asserted (correctly):


The assignments can happen in any order, as long
as they occur before the next sequence point.

> not on clarifying the precedence question.

But early on, Clark made this issue quite clear, writing:


This "grouping" determines precedence, not order of execution.

and


The grouping does, however, ensure that the following two
expressions are equivelant:

a = b = 0;

a = (b = 0);

I fail to see how you could possibly have made this any
clearer, even if you had inserted plenty of "EFFECTIVE"'s
along with all those various words about ordering.

> The OP wanted to know about precedence, not executional arcana.

So, the OP was simply being inarticulate when
he/she asked "what is the order of events?" ?

I must say that your perceptive powers are amazing.
Did that perception come to you even before the OP
somehow confirmed it via private email?

Since we are into intuiting now, I will intuit a bit.

You, Mr. Perkins, had developed a confusion between
"precedence" and "order of execution". You thought
such an equivalence was supported by your reading
and authorities you keep at hand, and you eagerly
marshalled them in support of your notion. But you
were seriously mistaken, as has become clear. For
some reason, being mistaken about well settled facts
is unpalatable to you. So you engage in convoluted
language games tending to divert attention away from
the fact that you were simply, technically mistaken.

I don't know if you are confused about being wrong,
or whether you hoped to confound others about it.
Either way, I think you should reconsider matters.
If you are so unwilling to be wrong that you are
unable to acknowledge plain mistakes, then that is
a serious handicap well worth curing. If you see
others as so gullable that a flurry of meaningless
words and extraneous new side issues will distract
them from the fundamental points of the discussion,
then that outlook is going to cause never-ending
problems for you and others with whom you interact.

I appreciate that these observations are somewhat
rude. But I think it is useful for you to realize
that people are not so easily confused.

-Larry Brasfield
Above opinions are my own.

(address anti-spammed)

Mike Hewson

unread,
Mar 23, 2001, 6:18:38 AM3/23/01
to

"Dr Mario" <drm...@twcny.rr.com> wrote in message
news:TChu6.264510$v.295...@typhoon.nyroc.rr.com...

> I am reading an example program out of a book, and I have come across
a
> statement that involves two variables, and the constant 0:
>
> m_nHScrollPos = m_nHPageSize = 0;
>
> This statement has me confused, and I'm not not quite sure what it
does.
> is it setting both of the variables to 0 at once? If so, what is the
order
> of events? Is it: 1) m_nHPageSize gets set to 0, then m_nHScrollPos gets
> set to m_nHPageSize (hence gettin 0)? Or is it this: 1) m_nHScrollPos
gets
> the value that is currently in m_nHPageSize, THEN 2) once that value has
> been safely assigned to something else, m_nHPageSize gets 0? Please help
> me, it is imperative that I know what this statement does. I have had

quite
> a bit of experience with the C++ language and never seen a statement like
> this before. Thank you very much for your help, it is GREATLY appreciated
> :-)
>
> --Mario
>
>
I think I've largely followed, sort of, the discussion launched from this
question.
I'm not going to answer it all. Hope I'm not OT.
I'll sidestep 'cos it's seems rather a sticky point beyond my brain box
boundary capacity.
I did try hard though....

Nonetheless, am I correct in saying that one could avoid the various
concerns expressed entirely by replacing

a = b = c;

with

b = c;
a = b;

as this expresses, without ambiguity, what I wanted by forcing a sequence
point ( by using a ";" )?
If so, I've done a little bit more typing but I haven't produced anything I
didn't intend ( assuming a,b,c and
= are otherwise well formed and accurate ideas in my mind ).
That is, I did not delegate to the compiler any decisions about
associativity, precedence et al.
Thus "unexpected effects" will not bite me, and I will not have planted a
possibly subtle bug with all
that may entail.

Secondly and more generally consider a statement of the form:

operand1 operator operand2 operator operand3; // One line version.

which is replaced by:

operand2 operator operand3; // Two line version.
operand1 operator operand2;

where operands are say.... a++ or function(x) ( anything requiring
evaluation really )
and the operator is anything sufficiently defined so that the compiler will
accept it as an operator,
( alluding to overloading here ). Now can anybody think of an instance where
I should or must
use the one line version and not the two line version?

Last question, ( and many thanks for reading this far ) I appreciate that
this "a=b=c;" stuff may
well be old news, thus standards, compilers and programmers have to deal
with it.
But shouldn't the "a=b=c;" style be "deprecated" now and in future, if not
already?
( Uh-oh! .... controversial... )

I guess I like the programming "method" of one idea per line, but I suppose
that then dereferences to the
issue of how fine grained an idea can be. Not much point having a high level
language if you can't
coarse grain.

Love this NG, learning heaps, now progressing from simply lurking ( brave
huh? Hey I've even downloaded
- AND started reading - the FAQ. Wow it's a big 'un! ).

Cheers, and thanks in advance. I'll stop now. Mike :-)


Anthony Williams

unread,
Mar 23, 2001, 6:31:48 AM3/23/01
to
"Mike Hewson" <hews...@sympac.com.au> wrote in message
news:99fbea$n4t$1...@perki.connect.com.au...

> Secondly and more generally consider a statement of the form:
>
> operand1 operator operand2 operator operand3; // One line version.
>
> which is replaced by:
>
> operand2 operator operand3; // Two line version.
> operand1 operator operand2;
>
> where operands are say.... a++ or function(x) ( anything requiring
> evaluation really )
> and the operator is anything sufficiently defined so that the compiler
will
> accept it as an operator,
> ( alluding to overloading here ). Now can anybody think of an instance
where
> I should or must
> use the one line version and not the two line version?
>

int a=0,b=0;

a=b=a++; // illegal, modifies a twice between sequence points

// probably what was intended is:
b=a++;
a=b;

Note that if a or b are UDTs, then the function call associated with the
operators forces a sequence point, and the original expression works

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer

Victor Bazarov

unread,
Mar 23, 2001, 1:03:56 PM3/23/01
to
"Anthony Williams" <ant...@nortelnetworks.com> wrote...

> int a=0,b=0;
>
> a=b=a++; // illegal, modifies a twice between sequence points
>
> // probably what was intended is:
> b=a++;
> a=b;

Which for built-in types is the same as
b=a++;

Why would someone add a= to that is beyond me.

It only makes sense if there are some side effects in calling the
assignment operator which cannot be achieved without it.

E. Mark Ping

unread,
Mar 23, 2001, 1:47:10 PM3/23/01
to
In article <3ABA9021...@acm.org>, Pete Becker <peteb...@acm.org> wrote:
>std::cout << f() << ' ' << g() << '\n';
>
>The output can be
>
>1 2
>
>or
>
>2 1

Hrm. I thought the above line was equivalent to (omitting the
newline):

((std::cout.operator<<(f())).operator<<(' ')).operator<<(g()))

And I thought there would be a sequence point after each function
call, before any expressions outside the function (1.8/17 in the
standard). The function calls are stacked here, and I'm not certain
what the full ramifications are. Could you explain in a little more
detail?
--
| "If hard data were the filtering criterion
Mark Ping | you could fit the entire contents of the
ema...@soda.CSUA.Berkeley.EDU | Internet on a floppy disk."
| - Cecil Adams, The Straight Dope Tells All

Adam Peterson

unread,
Mar 23, 2001, 1:49:49 PM3/23/01
to

"Victor Bazarov" <vAba...@dAnai.com> wrote in message
news:99g36e$k40$1...@nnrp.atgi.net...
Correct me if I'm wrong, but for built-in types, the above expression (with
sequence points) is equivalent to:

b=a;

Is it not?

b=a++;

sets b to the original value of a.

a=b;

restores that value to a.

Correct?


Pete Becker

unread,
Mar 23, 2001, 2:10:54 PM3/23/01
to
"E. Mark Ping" wrote:
>
> In article <3ABA9021...@acm.org>, Pete Becker <peteb...@acm.org> wrote:
> >std::cout << f() << ' ' << g() << '\n';
> >
> >The output can be
> >
> >1 2
> >
> >or
> >
> >2 1
>
> Hrm. I thought the above line was equivalent to (omitting the
> newline):
>
> ((std::cout.operator<<(f())).operator<<(' ')).operator<<(g()))
>
> And I thought there would be a sequence point after each function
> call, before any expressions outside the function (1.8/17 in the
> standard). The function calls are stacked here, and I'm not certain
> what the full ramifications are. Could you explain in a little more
> detail?

The standard does not require that f() and g() be called in any
particular order, just that each call be made before its result is
needed. (evaluating function arguments is not a side effect of a
function call, so is not controlled by the sequence points resulting
from the function calls). That's why iostreams use manipulators instead
of function calls for things like inserting newlines.

Victor Bazarov

unread,
Mar 23, 2001, 2:24:01 PM3/23/01
to
"Adam Peterson" <ah...@email.byu.edu> wrote in message
news:99g5vp$3vi$1...@acs2.byu.edu...

Absolutely. I wasn't thinking, sorry. Thank you for the correction.

Ray Fischer

unread,
Mar 23, 2001, 9:41:15 PM3/23/01
to
Adam Peterson <ah...@email.byu.edu> wrote:
>"Victor Bazarov" <vAba...@dAnai.com> wrote in message

>> Which for built-in types is the same as
>> b=a++;
>>
[...]


>Correct me if I'm wrong, but for built-in types, the above expression (with
>sequence points) is equivalent to:
>
>b=a;
>
>Is it not?
>
>b=a++;
>
>sets b to the original value of a.
>
>a=b;
>
>restores that value to a.
>
>Correct?

I wouldn't bet on it. When is the increment done? Before the final
assign or after?

Reply all
Reply to author
Forward
0 new messages