There's a library that I understand is being proposed for Boost:

http://www.codeproject.com/vcpp/stl/PGIL.asp

It does useful things, but it runs straight against the commonly given
advice (with which I happen to agree) that one should not override operator,
unless using expression templates that ensure left-to-right evaluation.

So now, in the referenced article, the author makes the comment: "
Overloading operator comma is sometimes viewed as a bad practice [3].
However, it has been done with success in eg. the Generative Matrix
Computation Library and Blitz to initialize matrices (see [4]) and [5]). The
Initialization Library overloads the comma operator in a safe manner by
letting set_cont and set_map return an object that is responsible for the
initialization. Therefore it takes explicit action from the programmer to
begin using the overloaded operator,(). "

I think the mentioned libraries do employ expression templates, while the
initialization library does not. So I am unsatisfied. Anyone here can soothe
my concerns? Is overloading the comma operator considered harmless after
all?


Andrei



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Andrei Alexandrescu \(See Website for Email\)" <SeeWebsiteForEmail@moderncppdesign.com> writes:

> There's a library that I understand is being proposed for Boost:
>
> http://www.codeproject.com/vcpp/stl/PGIL.asp
>
> It does useful things, but it runs straight against the commonly given
> advice (with which I happen to agree) that one should not override operator,
> unless using expression templates that ensure left-to-right evaluation.
>
> So now, in the referenced article, the author makes the comment: "
> Overloading operator comma is sometimes viewed as a bad practice [3].
> However, it has been done with success in eg. the Generative Matrix
> Computation Library and Blitz to initialize matrices (see [4]) and [5]). The
> Initialization Library overloads the comma operator in a safe manner by
> letting set_cont and set_map return an object that is responsible for the
> initialization. Therefore it takes explicit action from the programmer to
> begin using the overloaded operator,(). "
>
> I think the mentioned libraries do employ expression templates, while the
> initialization library does not. So I am unsatisfied. Anyone here can soothe
> my concerns? Is overloading the comma operator considered harmless after
> all?

Before we get too wound up over operator, "abuses" over here, please
take a look at Vladimir Prus' excellent reply to Andrei's duplicate
posting at news://gmane.comp.lib.boost.devel:

   http://lists.boost.org/MailArchives/boost/msg66657.php

Thanks,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Andrei Alexandrescu \(See Website for Email\)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:<2l16v8F70ge8U1@uni-berlin.de>...
>
> I think the mentioned libraries do employ expression templates, while the
> initialization library does not. So I am unsatisfied. Anyone here can soothe
> my concerns? Is overloading the comma operator considered harmless after
> all?
> 
> 
> Andrei
> 
> 

I can't get by this bug in the very first example of the documentation
(*** emphasis added):

vector<int>  primes;
set_cont( ***v*** ) += 1, 2, 3, 5, 7, 11;


The problem, IMHO, is that ',' implies that the left side will be
evaluated before the right side, as ',' is a known sequence point.

The code may be less misleading if it were changed to use an operator
that is not a sequence point:

vector<int> primes;
set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;

Of course, '+' has its own problems, in that it implies addition,
rather than concatenation.

joshua lehrer
factset research systems
NYSE:FDS

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:ubris84pf.fsf@boost-consulting.com...
 > "Andrei Alexandrescu \(See Website for Email\)"
<SeeWebsiteForEmail@moderncppdesign.com> writes:
 >
 > > There's a library that I understand is being proposed for Boost:
 > >
 > > http://www.codeproject.com/vcpp/stl/PGIL.asp
 > >
 > > It does useful things, but it runs straight against the commonly given
 > > advice (with which I happen to agree) that one should not override
operator,
 > > unless using expression templates that ensure left-to-right evaluation.
 > >
 > > So now, in the referenced article, the author makes the comment: "
 > > Overloading operator comma is sometimes viewed as a bad practice [3].
 > > However, it has been done with success in eg. the Generative Matrix
 > > Computation Library and Blitz to initialize matrices (see [4]) and [5]).
The
 > > Initialization Library overloads the comma operator in a safe manner by
 > > letting set_cont and set_map return an object that is responsible for
the
 > > initialization. Therefore it takes explicit action from the programmer
to
 > > begin using the overloaded operator,(). "
 > >
 > > I think the mentioned libraries do employ expression templates, while
the
 > > initialization library does not. So I am unsatisfied. Anyone here can
soothe
 > > my concerns? Is overloading the comma operator considered harmless after
 > > all?
 >
 > Before we get too wound up over operator, "abuses" over here, please
 > take a look at Vladimir Prus' excellent reply to Andrei's duplicate
 > posting at news://gmane.comp.lib.boost.devel:
 >
 >    http://lists.boost.org/MailArchives/boost/msg66657.php

And you may also want to look at my answer to Vladimir Prus' answer, where I
mention that I am mostly worried about order of evaluation of operator
comma, which that post seems to not address. :o)


Andrei



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Joshua Lehrer" <usenet_cpp@lehrerfamily.com> wrote in message
news:31c49f0d.0407071113.31475bbe@posting.google.com...
 > The problem, IMHO, is that ',' implies that the left side will be
 > evaluated before the right side, as ',' is a known sequence point.

My point too.

 > The code may be less misleading if it were changed to use an operator
 > that is not a sequence point:
 >
 > vector<int> primes;
 > set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;
 >
 > Of course, '+' has its own problems, in that it implies addition,
 > rather than concatenation.

Ouch!!! Romanians have a saying: you escape from the lake to drown in the
well. :o)

Andrei



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Joshua Lehrer wrote:
 > The code may be less misleading if it were changed to use an operator
 > that is not a sequence point:
 >
 > vector<int> primes;
 > set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;
 >
 > Of course, '+' has its own problems, in that it implies addition,
 > rather than concatenation.

Since += is used as concantenation anyway, and + in std::basic_string
(which is also container) already has this meaning, I like you proposal
more that using , . It's just quite logical to say "let's add to
container some elements". This way we just add syntax we know (and like)
in std::basic_string to other containers. What bothers me is quite
different semantics of this syntax in context of said library (and that
would be strong reason to keep using , ).


B.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Joshua Lehrer wrote:
 >I can't get by this bug in the very first example of the documentation
 >(*** emphasis added):
 >
 >vector<int>  primes;
 >set_cont( ***v*** ) += 1, 2, 3, 5, 7, 11;
 >
 >
 >The problem, IMHO, is that ',' implies that the left side will be
 >evaluated before the right side, as ',' is a known sequence point.
 >
 >The code may be less misleading if it were changed to use an operator
 >that is not a sequence point:
 >
 >vector<int> primes;
 >set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;
 >
 >Of course, '+' has its own problems, in that it implies addition,
 >rather than concatenation.

I don't agree, I think that the comma operator makes it look more like
POD initialization and thus more natural. I for one don't usually
think about sequence points and readability trumps in this case.

Looking over the proposal I saw map initialization has changed.
map<const char*,int>  months;
set_map( months ) += "january",   31, "february", 28,
                      "march",     31, "april",    30,
                      "may",       31, "june",     30,
                      "july",      31, "august",   31,
                      "september", 30, "october",  31,
                      "november",  30, "december", 31;

Which gives an error at runtime if the order of params is wrong. Does
anyone know why this method is used rather than operator()? operator()
was used in the CUJ article and it reports errors at compile time.

In the CUJ article the above example would look like this:
map<string, int> months;
assign( months ) ("Jan", 31)("Feb",28); // etc.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Andrei Alexandrescu \(See Website for Email\)" <SeeWebsiteForEmail@moderncppdesign.com> writes:

> There's a library that I understand is being proposed for Boost:
> 
> http://www.codeproject.com/vcpp/stl/PGIL.asp
> 
> It does useful things, but it runs straight against the commonly given
> advice (with which I happen to agree) that one should not override operator,
> unless using expression templates that ensure left-to-right evaluation.
> 
> So now, in the referenced article, the author makes the comment: "
> Overloading operator comma is sometimes viewed as a bad practice [3].
> However, it has been done with success in eg. the Generative Matrix
> Computation Library and Blitz to initialize matrices (see [4]) and [5]). The
> Initialization Library overloads the comma operator in a safe manner by
> letting set_cont and set_map return an object that is responsible for the
> initialization. Therefore it takes explicit action from the programmer to
> begin using the overloaded operator,(). "
> 
> I think the mentioned libraries do employ expression templates, while the
> initialization library does not. So I am unsatisfied. Anyone here can soothe
> my concerns? Is overloading the comma operator considered harmless after
> all?

As a general rule, I think this is a good one.

However, people will always argue against coding standard rules,
especially where there is a *cool* trick which violates the rule but
results in an apparant *safe* usage.

This trick can bite with something that I can imagine people wanting
to do in the initializer.

  vector<int>  v;
  set_cont( v ) += 1, *(v.begin ());

Catching this adds a lot of pressure on Code Reviewers or automated
analysis tools to determine that there's something wrong here.  A very
clever static analysis tool might catch the above case but can't do so
in all cases.  And most will just warn that you're overloading the
operator!

Whats worse it may work on 4 or 5 of you platforms or only show in
release builds with no symbols.  Not my faviourite type of bug!

Given that not all developers have the same level of experience, if
code is to be modified/reviewed by a team of developers I think the
code should be at least readable by everybody.  If one of your team
may write code like the above and not understand the consequences then
this rule should not be violated.

Regards,


Richard






> 
> 
> Andrei
> 
> 
> 
>       [ See http://www.gotw.ca/resources/clcm.htm for info about ]
>       [ comp.lang.c++.moderated.    First time posters: Do this! ]

-- 
Richard Corden
To reply remove 's' from address

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Joshua Lehrer wrote:
> 
> The code may be less misleading if it were changed to use an operator
> that is not a sequence point:
> 
> vector<int> primes;
> set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;
> 
> Of course, '+' has its own problems, in that it implies addition,
> rather than concatenation.

And it has higher priority than '+=', so the above expression is
parsed as
  set_cont(primes) += (1 + 2 + 3 + 5 + 7 + 11);
well, more precisely as
  set_cont(primes) += (((((1 + 2) + 3) + 5) + 7) + 11);
which is equivalent to 'set_cont(primes) += 29;'

Thus, one would need to write
  (((((set_cont(primes) += 1) + 2) + 3) + 5) + 7) + 11;
- not really nice...

Something like
  set_cont(primes) += 1 += 2 += 3 += 5 += 7 += 11;
would not work, either: because of the right-to-left associativity of
that operator, it is read as
  set_cont(primes) += (1 += (2 += (3 += (5 += (7 += 11)))));
which is, of course, ill-formed.

The ',' operator seems to be the only one having the right priority
and associativity for the purpose. However, as already pointed out
before, the fact that it doesn't constitute a sequence point anymore
once overloaded risks to be misleading for the non-averted user:
  int i = 0;
  set_cont(primes) += ++i, ++i, ++i;
breaks.

Furthermore, 1 is not really a prime :-)

Falk

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Abrahams <dave@boost-consulting.com> wrote in message
news:<ubris84pf.fsf@boost-consulting.com>...
> "Andrei Alexandrescu \(See Website for Email\)"
> <SeeWebsiteForEmail@moderncppdesign.com> writes:

> > There's a library that I understand is being proposed for Boost:

> > http://www.codeproject.com/vcpp/stl/PGIL.asp

> > It does useful things, but it runs straight against the commonly
> > given advice (with which I happen to agree) that one should not
> > override operator, unless using expression templates that ensure
> > left-to-right evaluation.

> > So now, in the referenced article, the author makes the comment: "
> > Overloading operator comma is sometimes viewed as a bad practice
> > [3].  However, it has been done with success in eg. the Generative
> > Matrix Computation Library and Blitz to initialize matrices (see
> > [4]) and [5]). The Initialization Library overloads the comma
> > operator in a safe manner by letting set_cont and set_map return an
> > object that is responsible for the initialization. Therefore it
> > takes explicit action from the programmer to begin using the
> > overloaded operator,(). "

> > I think the mentioned libraries do employ expression templates,
> > while the initialization library does not. So I am
> > unsatisfied. Anyone here can soothe my concerns? Is overloading the
> > comma operator considered harmless after all?

> Before we get too wound up over operator, "abuses" over here, please
> take a look at Vladimir Prus' excellent reply to Andrei's duplicate
> posting at news://gmane.comp.lib.boost.devel:

>    http://lists.boost.org/MailArchives/boost/msg66657.php

I looked at it, but I don't see where it addressed Andrei's concerns.
In the examples, there is no problem, but suppose I have something like:

    extern int         i ;

    std::vector< int > v ;
    i = 0 ;
    set_cont( v ) += f( i ++ ), g( i ++ ) ;

Does it guarantee that in f, i == 0, and in g, i == 1 ?  If not, you're
violating a fundamental guarantee of the , operator.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi!

Andrei Alexandrescu (See Website for Email) wrote:
 > And you may also want to look at my answer to Vladimir Prus' answer, where I
 > mention that I am mostly worried about order of evaluation of operator
 > comma, which that post seems to not address. :o)

How about a proposal to the comittee that the arguments to the
comma operator (regardless if overloaded or builtin) should
evaluate left to right? I would prefer this, too.

Frank


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi!

Joshua Lehrer wrote:
 > The code may be less misleading if it were changed to use an operator
 > that is not a sequence point:
 >
 > vector<int> primes;
 > set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;
 >
 > Of course, '+' has its own problems, in that it implies addition,
 > rather than concatenation.

Apart from the implied meaning the main problem is: you are going
to append the number 29 to the vector. The operator + has a much
higher precedence than operator +=. Thus only the comma operator
can be used here.

Or you need to wrap at least the first number with some class,
that stores all numbers, and then operator += appends the stored
numbers to the vector. But I wouldn't like this implementation at
all.

Frank


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Motti Lanzkron <mlanzkron@yahoo.co.uk> wrote:
 > Joshua Lehrer wrote:
 >  >I can't get by this bug in the very first example of the documentation
 >  >(*** emphasis added):
 >  >
 >  >vector<int>  primes;
 >  >set_cont( ***v*** ) += 1, 2, 3, 5, 7, 11;
 >  >
 >  >
 >  >The problem, IMHO, is that ',' implies that the left side will be
 >  >evaluated before the right side, as ',' is a known sequence point.
 >  >
 >  >The code may be less misleading if it were changed to use an operator
 >  >that is not a sequence point:
 >  >
 >  >vector<int> primes;
 >  >set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;

1 is not a prime!

 >  >
 >  >Of course, '+' has its own problems, in that it implies addition,
 >  >rather than concatenation.

I like the operator '%' that the boost::format library used:

   set_cont(primes) %= 2 % 3 % 5 % 7 % 11;

With ',' and '+' there is ambiguity with other natural meanings of the
operator (eg. + could be addition, and , is a sequence point), but the
idea of 'mod 2 mod 3 mod 5 mod 7 mod 11' is insane, so there is no
confusion.

Also, what about the trusty '<<' operator?
   set_cont(primes) << 2 << 3 << 5;

 > I don't agree, I think that the comma operator makes it look more like
 > POD initialization and thus more natural. I for one don't usually
 > think about sequence points and readability trumps in this case.

IMHO something that is approximately natural is worse than something
unnatural, because the newbie (or even the experienced programmer)
won't be on the lookout for paradoxical corner cases.
(Having said that, I can't think of any such cases for this proposal).

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze@gabi-soft.fr wrote:
> [...] suppose I have something like:
> 
>     extern int         i ;
> 
>     std::vector< int > v ;
>     i = 0 ;
>     set_cont( v ) += f( i ++ ), g( i ++ ) ;
> 
> Does it guarantee that in f, i == 0, and in g, i == 1 ?  If not, you're
> violating a fundamental guarantee of the , operator.

Maybe it would be better to overload operator '<<' rather than '+=' and ','?
C++ programmers are used to working with C++ streams, therefore it should be
more obvious to them that the following produces UB:

  set_cont(v) << f(i++) << g(i++);

Falk

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <2l60spF9e5r6U1@uni-berlin.de>, Frank Birbacher 
<bloodymir.crap@gmx.net> writes
>Hi!
>
>Andrei Alexandrescu (See Website for Email) wrote:
> > And you may also want to look at my answer to Vladimir Prus' answer, where I
> > mention that I am mostly worried about order of evaluation of operator
> > comma, which that post seems to not address. :o)
>
>How about a proposal to the comittee that the arguments to the
>comma operator (regardless if overloaded or builtin) should
>evaluate left to right? I would prefer this, too.

I think that would require an entirely new syntax. Just requiring left 
to right evaluation of arguments would not be sufficient.


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <843a4f78.0407081948.2aa0fdea@posting.google.com>, Old Wolf 
<oldwolf@inspire.net.nz> writes
>I like the operator '%' that the boost::format library used:
>
>   set_cont(primes) %= 2 % 3 % 5 % 7 % 11;

However that will certainly not work for builtin types owing to the 
relative precedence of %= and %


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Motti Lanzkron <mlanzkron@yahoo.co.uk> wrote in message
news:<hpupe092sjsv70nj6g83h0cpkf28d6h1uv@4ax.com>...
> Joshua Lehrer wrote:
>  >I can't get by this bug in the very first example of the documentation
>  >(*** emphasis added):

>  >vector<int>  primes;
>  >set_cont( ***v*** ) += 1, 2, 3, 5, 7, 11;

>  >The problem, IMHO, is that ',' implies that the left side will be
>  >evaluated before the right side, as ',' is a known sequence point.

>  >The code may be less misleading if it were changed to use an
>  >operator that is not a sequence point:

>  >vector<int> primes;
>  >set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;

>  >Of course, '+' has its own problems, in that it implies addition,
>  >rather than concatenation.

And as another poster has pointed out, it doesn't have the right
precedance.

> I don't agree, I think that the comma operator makes it look more like
> POD initialization and thus more natural. I for one don't usually
> think about sequence points and readability trumps in this case.

If you don't think about sequence points, you don't write correct C++:-)
(or rather :-( -- it would be better if we didn't have to constantly
think about them.

In fact, most programmers I know don't think of , as an operator, but
rather as punctuation.  Which makes parsing the statement somewhat
problematic.

> In the CUJ article the above example would look like this:
> map<string, int> months;

> assign( months ) ("Jan", 31)("Feb",28); // etc.

Which doesn't overload the , operator.

Frankly, what's wrong with:

    months.with( "Jan", 31 ).with( "Feb", 28 ) ...

Of course, you'll need a wrapper for the std::map, but that's usually
the case anyway -- if someone writes months[ "Jen" ], I want an
exception or an assertion failure, not a result of 0.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Andrei Alexandrescu \(See Website for Email\)" <SeeWebsiteForEmail@moderncppdesign.com> writes:

 > There's a library that I understand is being proposed for Boost:
 >
 > http://www.codeproject.com/vcpp/stl/PGIL.asp
 >
 > It does useful things, but it runs straight against the commonly given
 > advice (with which I happen to agree) that one should not override operator,
 > unless using expression templates that ensure left-to-right evaluation.
 >
 > So now, in the referenced article, the author makes the comment: "
 > Overloading operator comma is sometimes viewed as a bad practice [3].
 > However, it has been done with success in eg. the Generative Matrix
 > Computation Library and Blitz to initialize matrices (see [4]) and [5]). The
 > Initialization Library overloads the comma operator in a safe manner by
 > letting set_cont and set_map return an object that is responsible for the
 > initialization. Therefore it takes explicit action from the programmer to
 > begin using the overloaded operator,(). "
 >
 > I think the mentioned libraries do employ expression templates, while the
 > initialization library does not. So I am unsatisfied. Anyone here can soothe
 > my concerns? Is overloading the comma operator considered harmless after
 > all?

(+) PGIL makes it easier to fill STL contianers.

(-) It overloads operator, which may confuse some because overloaded
     operator, doesn't guarantee the order of evaluation, while
     builtin operator, does.

I used to think the disadvantage of this technique (which I don't
     think is new; I am pretty sure I saw a proof-of-concept for
     something similar in 1998 or so) outweighed the advantage. But
     I've come to think many C++ programmers don't know the builtin
     operator, guarantees order of evaluation in the first place.

To them, the ',' in 'foo(1,2,3)' is the comma. The fact that it
     isn't the builtin operator, but instead an argument seperator, is
     unrecognized; to most, if it looks like a comma, it is a
     comma. And comma as argument separator does not guarantee order
     of evaluation.

I believe the confusion this overload of operator, may cause already
     exists, and this overload doesn't significantly worsen the
     situation. So it's a disadvantage, but it's outweighed by the
     gain of easier initialization.

That being said, familarity with <iostream> leaves me prefering
     operator<< to operator, . (The disadvantage of operator<< is that
     its precedence isn't low enough - but I don't consider that an
     unacceptable disadvantage.)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze@gabi-soft.fr wrote:
>
>> I don't agree, I think that the comma operator makes it look more like
>> POD initialization and thus more natural. I for one don't usually
>> think about sequence points and readability trumps in this case.
>
>If you don't think about sequence points, you don't write correct C++:-)
>(or rather :-( -- it would be better if we didn't have to constantly
>think about them.

I did say that I don't *usually* thing about sequence points not
never. Truth be told I overstated matters, I hardly ever consciously
think of sequence points, I don't think this means that I don't write
correct C++ (well I wouldn't think that would I?). After all in the
vast majority of code sequence points (other than ';') have no effect.

I would be interested in being proven wrong on this.

All this is assuming "reasonable" code, for the sake of this argument
I'll define "reasonable" to be not something like this:
i = foo(i+=2, i-=2); 

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Motti Lanzkron <mlanzkron@yahoo.co.uk> wrote in message
news:<ibo1f0huqfnn49sm47q6hdqj55bsoba1t0@4ax.com>...
> kanze@gabi-soft.fr wrote:

> >> I don't agree, I think that the comma operator makes it look more
> >> like POD initialization and thus more natural. I for one don't
> >> usually think about sequence points and readability trumps in this
> >> case.

> >If you don't think about sequence points, you don't write correct
> >C++:-) (or rather :-( -- it would be better if we didn't have to
> >constantly think about them.

> I did say that I don't *usually* thing about sequence points not
> never. Truth be told I overstated matters, I hardly ever consciously
> think of sequence points, I don't think this means that I don't write
> correct C++ (well I wouldn't think that would I?). After all in the
> vast majority of code sequence points (other than ';') have no effect.

Yes.  I suspect that most of us have in fact developed "sequence point
safe" idioms a long time ago, and regularly use these.  For that matter,
one could argue that exception in a few rare cases, cleanly written code
will be sequence point safe.

So it's probable that most of the time we don't think consciously about
them.  At least until for some reason or another, we are led to step
outside of our usual idioms.

Part of the problem here, of course, is that the comma operator isn't
part of our usual idioms (which is more or less what you were saying).
But that is just the problem here -- the code leaves our usual idioms,
and requires additional conscious reflection about what it does.  And
that reflection is likely to be wrong, because once we leave the usual
idioms, and start thinking about sequence points, we know that the comma
operator is a sequence point; more importantly, in this case, we know
that it creates an evaluation order constraint.

Unless, of course, someone has overloaded it to not respect that
constraint.

Note that the comma operator is particularly pernicious with regards to
this problem -- when other operators are involve, since I presumably
know the types involved, I also immediately know whether I am dealing
with a built-in operator or a user defined operator.  Whereas with the
comma operator, the built-in operator is always legal.  

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Andrei Alexandrescu (See Website for Email) wrote:
> "Joshua Lehrer" <usenet_cpp@lehrerfamily.com> wrote in message
> news:31c49f0d.0407071113.31475bbe@posting.google.com...
<snip> 
> > The code may be less misleading if it were changed to use an operator
> > that is not a sequence point:
> >
> > vector<int> primes;
> > set_cont(primes) += 1 + 2 + 3 + 5 + 7 + 11;
> >
> > Of course, '+' has its own problems, in that it implies addition,
> > rather than concatenation.
> 
> Ouch!!! Romanians have a saying: you escape from the lake to drown in the
> well. :o)

In English: out of the frying pan, into the fire.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]