On 14 Jul 1998 05:02:05 GMT, AllanW@my-dejanews.com <AllanW@my-dejanews.com>
>In article <35AA8D83.59E2@wizard.net>,
>  James Kuyper <kuyper@wizard.net> wrote:
>> On the other hand, having operator,() available for overloading has
>> produced a lot "interesting" tricks in C++.
>"Tricks" that weren't around in C?  Like what?
[...]
>> It can be used to make a
>> function which actually takes only one argument look like it can handle
>> an arbitrarily long list of arguments.
>No, that isn't so.
>    void one_arg(int i);
>    one_arg(10, 20, 30, 40); // Error
>This is illegal because it has four arguments.
>    one_arg((10, 20, 30, 40)); // Ok
>This is legal because it has one argument, the number 40.  But the
>extra parens don't allow it to "look like" anything.  In any case
>this isn't generally useful (because the first three "arguments"
>are discarded).

You can get the desired affect by defining a base argument class which
contains a list of arguments, and defines operator,() by appending
it's argument list to that of the right-hand argument. So then if
VarArgBase is your base class, and VarArg<T> a templated derivative to
handle different argument classes, your function could be defined as:

void func( VarArgBase& );

... and used as ...

VarArg<int> arg1 = 5;
VarArg<float> arg2 = 1.0;
VarArg<char> arg3 = 'a';

func( (arg1,arg2,arg3) );

... and internally the function can extract all the arguments,
perform runtime type-checking, etc...

-Paul Murray



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

Paul Murray<murray-paul@usa.net> wrote:
>You can get the desired affect by defining a base argument class which
>contains a list of arguments, and defines operator,() by appending
>it's argument list to that of the right-hand argument. So then if
>VarArgBase is your base class, and VarArg<T> a templated derivative to
>handle different argument classes, your function could be defined as:
>
>void func( VarArgBase& );
>
>... and used as ...
>
>VarArg<int> arg1 = 5;
>VarArg<float> arg2 = 1.0;
>VarArg<char> arg3 = 'a';
>
>func( (arg1,arg2,arg3) );
>
>... and internally the function can extract all the arguments,
>perform runtime type-checking, etc...

You can do this more conveniently by defining a class with
an operator template.  Then you can say

  func( (Var(), 5, 1.0, 'a') );

I don't think there's any syntactically nicer way to express
this in C++ using operator,().  An alternative is to use a
different operator:

  func << 5 << 1.0 << 'a';

The meaning is familiar to readers by analogy with iostreams.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

Siemel Naran wrote:

[...]

> In "A,B,C", temporaries created in A won't be destroyed until C is
> finished.  This is because the statement is thought of as one
> expression.  So if the destructors of these temporary variables
> have side effects -- for example, they may update local variables
> of the function or write data to a file -- these effects will be
> seen only be seen after C is finished.  Note that if the temps
> created by A are not freed before executing B or C, our program will
> use more run-time memory.

A possible use I can see for this is locking a single expression
(like a function call).

Say you have a class Lock which is normally used like this:

Mutex myMutex;

void f()
{
  ...
  { // The code in this block must have myMutex locked
    Lock lock(myMutex);
    do_something();
    do_something_else();
  } // Lock destructor unlocks the mutex
  ...
}

Then if you want to lock for just one function call, you can do

void g()
{
  ...
  Lock(myMutex), call_the_function();
  ...
}

which creates a temporary Lock, which is destructed after
the function returns. Also the nasty name of the Lock is avoided.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35aef9a7.5559984@news.eur.sprynet.com>,
  1xx754.273x@compuserve.com (Martin Aupperle) wrote:
> On 14 Jul 1998 23:30:41 GMT, AllanW@my-dejanews.com wrote:
>
> >
> >Getting back to this specific case:  instead of using operator, to
> >allow creation of a set, consider this:
> >    template<class T>std::set<T>MakeSet(int num,...) {
> >        std::set<T> s;
> >        va_list v;
> >        va_start(v,num);
> >        while (num--)
> >            s.insert(va_arg(v, T));
> >        return s;
> >    }
> >This is not only easier to read and maintain (IMHO) than the
> >comma-seperator overload, it's also more efficient, since it copies
> >the set 1 or 2 times instead of N*(N-1)+1 times.  And yet usage is
> >quite similar:
> >    std::set<int> s(MakeSet<int>(5, 1,3,5,7,9));
> >(If I had designed this explicitly for set<int>, instead of for any
> >set<T>, then I would have omitted the argument count, instead using
> >a trailing 0 value.)
> >
>
> Some annotations:
> 1. The VA-version is *not* equal to the overloaded operator version.
> Consider
>  s = 1, 2, 3. 0, f();
> and
>  s.set( 6, 1, 2, 3.0, f() );
>
> where f is assumed to return something that can be converted to int.
>
> The latter is wrong for at least three reasons. BUT IT COMPILES, and
> that's why I usually fire people that write VA-functions for things
> like that (I personally are against shooting them because they might
> go and work for the competition and spoil *their* code - and that's
> good for us).

Good point; I hadn't considered that.  (I've also never done anything
like this until I tried to respond to the operator, argument.)

> 2. The operator version is more efficient than the VA-version, because
> it does not need to parse the argument list at runtime. If you use an
> inline function, it (nearly) boils down to
>  s.insert( 1 );
>  s.insert( 2 );
>  ...
>  s.insert( f() );
>
> Since the operator function returns a reference, no copying of s takes
> place.

But with all those member function calls, this still isn't as efficient
as
    #define ASIZE(x) (sizeof(x)/sizeof(x[0]))
    int values[] = { 6, 1, 2, 3.0, f() };
    set<int> s(values, values + ASIZE(values));
which in my mind is more readable than anything I've seen in this thread
so far.

> 3. I personally do not use operator , but operator <<, and I write
>
>  SomeCOntainer sc;
>  sc << 1 << 2 << 3 << 4;
>

Well, I am impressed.  This makes a lot of sense.

I still stand by my argument to avoid using operator anything where
it's not intuitive.  Earlier I claimed that this meant mimicing the
built-in operators.  Let me amend this to say that it should mimic
one of the standard operators.

The built-in meaning of operator<< is bit shift.  [[ What would it
mean to bit-shift a set left once, then twice, then 3 and 4 times?
Nothing! ]] However, since operator<< is now the "insertion" operator
in the standard C++ library, and every C++ programmer will be
expected to know this, then using it to insert into a set isn't so
much of a stretch.  In other words,

> This makes clear what happens: The values "flow into the container".

I agree.  And I like this version, for exactly the same reasons that
I dislike operator, or operator+.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
>
> Not quite.  I think Valentin's point (which he could have stated clearer)
> is that there is no type for which you can overload the comma operator
> and the ++ operator is defined.  The result is that if operator, is
> overloaded, and the above expression is legal, so is operator++.  Which
> means that they are also functions; the logical equivalent of the expression
> is:  g(f(x),f(x)).  Which if the f's is called first is unspecified, but
> there is no undefined behavior (because the call is a sequence point).
>
> I'll admit it's a subtle point, and easily missed.

Ah, each call to _f_ is a sequence point. Yes, that's easily missed.

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

In article <6oft5g$mne$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
> In article <6oeehg$5ba$1@nnrp1.dejanews.com>,
>   AllanW@my-dejanews.com wrote:
>
> > > On the other hand, having operator,() available for overloading has
> > > produced a lot "interesting" tricks in C++.
> > "Tricks" that weren't around in C?  Like what?
>
> Obviously, if they involve operator overloading.

Operator() is the function-call operator.  It should be used for any
object that acts as if it were a function; among other useful purposes,
this allows us to pass functions to other functions.  The best example
of this is the "functors" of the STL.

The only "trick" I know of (in the negative sense -- is there any
other?) is it's misuse for index-like operators, since so many other
languages use () for indexing.  "Say it in code" -- if you want to
use an index, use operator[], not operator().

> > > It can be used to catenate
> > > containers together using APL-like syntax.
> > Can you demonstrate?
>
> I got the following from Paul Lucas:
>
>     Set< int >&
>     operator,( Set< int >& s , int i )
>     {
>         s.insert( i ) ;
>         return s ;
>     }
>
> This allows you to write things like:
>
>     Set< int >         s ;
>     s = 1 , 3 , 5 , 7 , 9 ;
>
> (Personally, this is a bit too subtle for my tastes, but it works.  Provided
> you provide the necessary set<int>::operator=( int ) as well, of course.)

[Shudder]

Operator , is the comma operator -- it has no other name because it's use
is so specific.  The built-in version evaluates the left-hand argument,
including any side-effects, then throws out the result.  Then the right
hand argument is evaluated and returned.

As such, when I see code of the form:
    s = 1, 3, 5, 7, 9;
my first instinct is to assume that this is equivalent to
    s = (1, 3, 5, 7, 9);    // No it isn't
and then assume that the compiler will optimize this to
    s=9;                    // No it won't

Looking up the nitty-gritty details, I see that the assignment operator
has higher precedence than comma, so the expresison really evaluates to
    ((((s=1),3),5),7),9;
and again I assume the compiler will optimize:
    s=1;                    // Not when operator,(set<int>,int) is defined!
This assumption would be true for built-in types, of course.

And that defines the real problem that I have with this technique.
Overloading any operator should be done only if you (conceptually,
at least) do exactly what the built-in operator would have done.
So if you have defined operator+=, your class better be a numeric
type, and operator+= better increment that number by the given
amount and have no other side effects.  But the semantics of
operator, are so simple and it's defined for so many types, that
it's hard for me to imagine any good use for overloading it.

Imagine that you just spent 3 days tracking down a bug in a program,
and the bug turned out to be code like this:
    Employee e;
    e/=5;       // Get employee number 5
    e.marital_status = Employee::Married;
    e/5;        // Write employee number 5
which assumed that operator/= read the employee from the employee file,
and operator/ wrote the employee to the employee file.  What would you
do?  Personally, I would pick up my shotgun, drive to the home of the
responsible programmer, wait for him to come home, and then blow his
head off.  (This is legal in 37 of the 50 United States.)

Why?  Open any introductory C++ text for an explanation of operator
overloading.  You should see something along the lines of:
    It is, however, usually a good idea to use operator overloading
    to mimic conventional usage.
The reason for this is quite simple -- programmer expectations.  If an
operator is designed to do division, then you shouldn't redefine it to
do anything but division.  If it's designed to do indexing, then you
shouldn't redefine it to do anything but indexing.  If there is no
operator that conceptually does EXACTLY what you're defining, then your
definition should be a named function, not an operator.

[[ There's already precedent for using an operator in a completely new
way for certain class types -- operator<< and operator>>.  Which, in
my opinion, was a mistake -- these operations should have used a new
operator that didn't exist in C.  I wouldn't advocate switching to
that now, of course, but I hope we can limit this type of thing in
the future. ]]

There are exceptions.  For instance, operator+ and operator+= for
string-type classes are well-defined and expected by any programmer
that knows what a string is.  But imagine trying to use operator/ on
a string:
    string s("1234");
    string t(s/2);
Should string t contain "617"?  Should it contain "12"?  Should it
contain "234"?  Should it contain something else?  Should string s
be muted by this call?  Since the answer isn't obvious, operator/
shouldn't have been defined in the first place.

Paul Lucas advocates using operator overloading to make C++ look
more like APL.  On it's own, this is a bad idea -- APL has a couple
of jillion operators, including the "interpret" operator which makes
APL impossible to compile.  APL has strengths that C++ could never
have (and vice-versa).  Trying to use a C++ compiler to compile APL
code may seem satisfying as minor milestones are hit, but it will
result in code that can only be maintained by the original author.

C++ can borrow good ideas from other languages.  But in general,
trying to make C++ "look" more like some other language is a very
bad idea.  Naive translations to C++ from BASIC, or PASCAL, or
COBOL, or in fact any other language, are slow, fat, and hard to
maintain -- in short, the very reasons to use C++ no longer apply.

Getting back to this specific case:  instead of using operator, to
allow creation of a set, consider this:
    template<class T>std::set<T>MakeSet(int num,...) {
        std::set<T> s;
        va_list v;
        va_start(v,num);
        while (num--)
            s.insert(va_arg(v, T));
        return s;
    }
This is not only easier to read and maintain (IMHO) than the
comma-seperator overload, it's also more efficient, since it copies
the set 1 or 2 times instead of N*(N-1)+1 times.  And yet usage is
quite similar:
    std::set<int> s(MakeSet<int>(5, 1,3,5,7,9));
(If I had designed this explicitly for set<int>, instead of for any
set<T>, then I would have omitted the argument count, instead using
a trailing 0 value.)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

In comp.std.c++, on 14 Jul 1998 05:02:05 GMT
AllanW@my-dejanews.com <AllanW@my-dejanews.com> wrote:
>In article <35AA8D83.59E2@wizard.net>,
>James Kuyper <kuyper@wizard.net> wrote:
[much snippage]
>> However, the sheer invisibility
>> of the ',' operator makes me leery of using these tricks.
>The comma operator is useful when it's useful, and not at other times.

*chuckle* That's rather true of everything, isn't it?

>The only problem I note with it is it's potential abuse in
>index-expressions, since the syntax so nearly mimics that of so many
>other languages (see my notes in a separate post).  Other than that,
>it can be very useful in ANY place where multiple expressions must be
>evaluated within one statement.

The comma operator is pretty cute, and yes, it's useful for evaluating
multiple expressions in one statement.  And (as said in the parent
post to this) you can do things like:

   x++, x++;

because the comma operator guarantees that the left hand argument is
fully evaluated before proceeding (it has a sequence point).

Overloaded operator,(), though, is scary.  Once you overload it, it
becomes a function...  and because it's a function, there is no longer
a sequence point between the first and second parts of the
expression.

That can lead to some fairly serious kinds of unnoticed breakage, if you
have classes with ++ operators or similar which perform ++ operations on
(eg) integral members...

Suddenly:

   x++, x++;

*isn't* defined behaviour.  Urgh.

Later,

   David

--
| david@unico.com.au (David Goh, Unico Computer Systems, +61-3-9866-5688)
What is mind?  No matter.
What is matter?  Never mind.
                -- Thomas Hewitt Key, 1799-1875
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <35AA8D83.59E2@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > KNAPEN, GREGORY wrote:
> [snip]
> > > I mean the following two fragments mean the same-thing:
> >
> > Wrong.
> No, he was right.
>
> > The value of a ',' expression is the value of the second
> > assignement expression.
> True.  But the result of the whole expression is thrown away.
>
> >
> > > 1.
> > > int x =0;
> > > x=4,x++,x++;

You're right; I've used ',' so seldom that I forgot it's order of
precedence. I apologize for spouting nonsense. However, there is a
similar example possible where it isn't even legal to replace the ','
with the ';':

 x=(4,x++,x++);

> Did you even try this?  Compile the above, and add std::cout<<x at the

No - I was too sure of myself :-(

[further related mistakes deleted]
...
> > On the other hand, having operator,() available for overloading has
> > produced a lot "interesting" tricks in C++.
> "Tricks" that weren't around in C?  Like what?
>
> > It can be used to catenate
> > containers together using APL-like syntax.
> Can you demonstrate?

The basic technique is to derive a catenatable type from any standard
container (though it is most useable when applied to sequences), and
then to define

template<class T> class catenateable: public whatever
{
 // Other features of the class
public:
 catenateable operator,(const catenateable& other) const {
  // create and return a new container containing the
  // catenation of *this and other.
 }

 catenateable& operator,(const T& t) const {
  // create and return a new container containing *this
  // with t appended to it.
 }
}
Then you can do things like

 a = (b,c);

> > It can be used to make a
> > function which actually takes only one argument look like it can handle
> > an arbitrarily long list of arguments.
> No, that isn't so.
>     void one_arg(int i);
>     one_arg(10, 20, 30, 40); // Error
> This is illegal because it has four arguments.
>     one_arg((10, 20, 30, 40)); // Ok
> This is legal because it has one argument, the number 40.  But the
> extra parens don't allow it to "look like" anything.  In any case
> this isn't generally useful (because the first three "arguments"
> are discarded).
>

The arguments don't have to be discarded, if one or more of them are
user-defined types with corresponding overloaded operator,() members.

You are correct that the extra parenthesis are necessary, so it doesn't
look exactly like a function call, but it does look very similar.

> > However, the sheer invisibility
> > of the ',' operator makes me leery of using these tricks.
> The comma operator is useful when it's useful, and not at other times.

That's not a very useful observation; the question is, when is it
useful?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.1014b14d9a8af0e4989bb2@news.rmi.net>,
  jcoffin@taeus.com (Jerry Coffin) wrote:
> In article <6oeehg$5ba$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> says...
>
> [ ... ]
>
> > > > int x =0;
> > > > x=4,x++,x++;
> > >
> > > x ends up with a value of 1.
> > Sorry, no.  The first sub-expression modifies x to have the value 4.
> > This result is discarded as the comma operator turns to the second
> > sub-expression.  This increments the value in x to the value 5, and
> > returns the value 4 to the sub-expression.  But this value 4 is also
> > discarded as we turn to the final sub-expression.  Once again, the
> > value in x is incremented (this time to 6), and the old value of x
> > (5) returned as the result.  The comma operator's result is 5, so the
> > expression statement's result is 5.  This result is promptly discarded.
> >
> > Did you even try this?  Compile the above, and add std::cout<<x at the
> > end.  If you see 1 there is something seriously wrong.
>
> Not at all -- there's no sequence point between evaluation of the
> right side and the left side of the expression.  Ignoring other parts
> for the moment, the final result is the same as:
>
>  x = x++;

   No, comma operator has the lowest precedence, so the grouping is
    (x=4),x++,x++
 and not
    x= (4,x++,x++)


  Returning to original question - comma operator overloading can produce a
lot of syntaxic sugar. I've used one home-brewn library where it was used
consistently for something like  object<<buffer,number which filled 'object'
with 'number' elements from the array 'buffer', and ditto for output.

        Regards,
                Alex Krol

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

In article <MPG.1014b14d9a8af0e4989bb2@news.rmi.net>,
  jcoffin@taeus.com (Jerry Coffin) wrote:
> In article <6oeehg$5ba$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> says...
>
> [ ... ]
>
> > > > int x =0;
> > > > x=4,x++,x++;
> > >
> > > x ends up with a value of 1.
> > Sorry, no.  The first sub-expression modifies x to have the value 4.
> > This result is discarded as the comma operator turns to the second
> > sub-expression.  This increments the value in x to the value 5, and
> > returns the value 4 to the sub-expression.  But this value 4 is also
> > discarded as we turn to the final sub-expression.  Once again, the
> > value in x is incremented (this time to 6), and the old value of x
> > (5) returned as the result.  The comma operator's result is 5, so the
> > expression statement's result is 5.  This result is promptly discarded.
> >
> > Did you even try this?  Compile the above, and add std::cout<<x at the
> > end.  If you see 1 there is something seriously wrong.
>
> Not at all -- there's no sequence point between evaluation of the
> right side and the left side of the expression.

In article <6ogp49$9b5$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
> In article <6oft5g$mne$1@nnrp1.dejanews.com>,
>   jkanze@otelo.ibmmail.com wrote:
> > In article <6oeehg$5ba$1@nnrp1.dejanews.com>,
> >   AllanW@my-dejanews.com wrote:
> >
> > > > On the other hand, having operator,() available for overloading h=
as
> > > > produced a lot "interesting" tricks in C++.
> > > "Tricks" that weren't around in C?  Like what?
> >
> > Obviously, if they involve operator overloading.
>
> Operator() is the function-call operator.  It should be used for any
> object that acts as if it were a function; among other useful purposes,
> this allows us to pass functions to other functions.  The best example
> of this is the "functors" of the STL.

Agreed, but there is no mention of operator()() in any of the previous
postings.  We are only discussing operator,() here.

> The only "trick" I know of (in the negative sense -- is there any
> other?) is it's misuse for index-like operators, since so many other
> languages use () for indexing.  "Say it in code" -- if you want to
> use an index, use operator[], not operator().

There is room for discussion on this point. According to Barton and Nackm=
an,
for example, [] is NOT the index operator, but a projection operator,
precisely because the results are not a single element, but an array of
one less dimension.  And using () for the index operator is not necessari=
ly
counter-intuitive, although it isn't defined that way on the built-in
types.

> > > > It can be used to catenate
> > > > containers together using APL-like syntax.
> > > Can you demonstrate?
> >
> > I got the following from Paul Lucas:
> >
> >     Set< int >&
> >     operator,( Set< int >& s , int i )
> >     {
> >         s.insert( i ) ;
> >         return s ;
> >     }
> >
> > This allows you to write things like:
> >
> >     Set< int >         s ;
> >     s =3D 1 , 3 , 5 , 7 , 9 ;
> >
> > (Personally, this is a bit too subtle for my tastes, but it works.
Provided
> > you provide the necessary set<int>::operator=3D( int ) as well, of co=
urse.)
>
> [Shudder]

Well, I did say that it was too subtle for my tastes as well: I tend to
avoid overloaded operators too.

> Operator , is the comma operator -- it has no other name because it's u=
se
> is so specific.  The built-in version evaluates the left-hand argument,
> including any side-effects, then throws out the result.  Then the right
> hand argument is evaluated and returned.
>
> As such, when I see code of the form:
>     s =3D 1, 3, 5, 7, 9;
> my first instinct is to assume that this is equivalent to
>     s =3D (1, 3, 5, 7, 9);    // No it isn't
> and then assume that the compiler will optimize this to
>     s=3D9;                    // No it won't

And when I first see code like the above, I immediately suppose that the
comma operator must be overloaded, because there can be no rational reaso=
n
for it otherwise:-).

That doesn't mean that this is my preferred idiom: I generally provide a
member function with for such cases:

    s =3D Set().with( 1 ).with( 3 ).with( 5 ).with( 7 ).with( 9 ) ;

Is this more readable?  I don't know.  I do know that it is less error
prone when passing a temporary to a function:

     f( (Set() , 1 , 3 , 5 , 7 , 9) ) ;  // and you'd better not forget t=
he
                                         // extra parentheses
vs.  f( Set().with( 1 ).with( 3 ).with( 5 ).with( 7 ).with( 9 ) )
                                         // safer, but a lot more typing

I prefer the latter, despite the extra typing, but it IS a question
of style.

    [Lot's of justifiable critique of operator overloading deleted...]

> [[ There's already precedent for using an operator in a completely new
> way for certain class types -- operator<< and operator>>.  Which, in
> my opinion, was a mistake -- these operations should have used a new
> operator that didn't exist in C.  I wouldn't advocate switching to
> that now, of course, but I hope we can limit this type of thing in
> the future. ]]

Agreed.  Who knows what crazy overloads might be invented, like ++ to
advance through a linked list:-).

> There are exceptions.  For instance, operator+ and operator+=3D for
> string-type classes are well-defined and expected by any programmer
> that knows what a string is.  But imagine trying to use operator/ on
> a string:
>     string s("1234");
>     string t(s/2);
> Should string t contain "617"?  Should it contain "12"?  Should it
> contain "234"?  Should it contain something else?  Should string s
> be muted by this call?  Since the answer isn't obvious, operator/
> shouldn't have been defined in the first place.

For that matter: why shouldn't "1" + "2" be "3"?

I find the use of the comma operator in the example along the same lines
as using + for string concatenation -- it certainly doesn't correspond
to the built in operator, but it does correspond to a certain intuitive
interpretation.  The real problem with using it, IMHO, is that comma is
not just an operator; the REAL error was to define it as both an operator
and a separator.  Given the ambiguities that result from this, there is
no need in compounding the problem by overloading it, and adding to the
cases where people might reasonably expect to use it.

> Paul Lucas advocates using operator overloading to make C++ look
> more like APL.

I don't think that Paul Lucas would advocate this at all.  I don't think
he'd generally approve of abusing operator overloading.  I just happened
to learn this particular technique from him.

    [...]
> Getting back to this specific case:  instead of using operator, to
> allow creation of a set, consider this:
>     template<class T>std::set<T>MakeSet(int num,...) {
>         std::set<T> s;
>         va_list v;
>         va_start(v,num);
>         while (num--)
>             s.insert(va_arg(v, T));
>         return s;
>     }
> This is not only easier to read and maintain (IMHO) than the
> comma-seperator overload, it's also more efficient, since it copies
> the set 1 or 2 times instead of N*(N-1)+1 times.

It is impossible to maintain -- you can be quite sure that someone
will forget to update the first argument when removing an element.
Or pass a short to a MakeSet<int>.  As for efficiency, neither my
solution (the member function with) nor Paul's (overloaded operator,)
copy the set at all.

> And yet usage is
> quite similar:
>     std::set<int> s(MakeSet<int>(5, 1,3,5,7,9));
> (If I had designed this explicitly for set<int>, instead of for any
> set<T>, then I would have omitted the argument count, instead using
> a trailing 0 value.)

Which would have made it very difficult to insert a 0.  And made for
interesting behavior when you forgot the 0.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AB98DA.3DAA2463@acm.org>, petebecker@acm.org says...

[ ... ]

>  Nope, you've got your precedences inverted here. The comma operator is
> the only operator with lower precedence than assignment.

Oops -- quite right.  My apologies to all involved.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


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

AllanW@my-dejanews.com wrote:
[A much better explanation than I could have given about why overloading
operator,() bothers me.]
...
> Paul Lucas advocates using operator overloading to make C++ look
> more like APL.  On it's own, this is a bad idea -- APL has a couple
> of jillion operators, including the "interpret" operator which makes
> APL impossible to compile.  APL has strengths that C++ could never
> have (and vice-versa).  Trying to use a C++ compiler to compile APL
> code may seem satisfying as minor milestones are hit, but it will
> result in code that can only be maintained by the original author.
>
> C++ can borrow good ideas from other languages.  But in general,
> trying to make C++ "look" more like some other language is a very
> bad idea.  Naive translations to C++ from BASIC, or PASCAL, or
> COBOL, or in fact any other language, are slow, fat, and hard to
> maintain -- in short, the very reasons to use C++ no longer apply.

I agree; making C++ look like APL would be a bad idea. However,
borrowing ideas from APL is not.
One of APL's main advantages is that it allows you to write very simple
expressions that correspond to very complex but highly regular
operations on multi-dimensional arrays. Since those operations are
built-in features of the language, code that mainly involves such
operations can be optimized as well as or even better than corresponding
C code, despite the fact that APL is an interpreted language. C++
operator overloads make it possible to obtain much the same advantage in
compilable C++ code. valarray<> is the one-dimensional prototype for
what could be done.


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

In article <6oia4r$d5q$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
says...

[ ... ]

> From the FDIS, 1.8/18:
> In the evaluation of each of the expressions
>   a && b
>   a || b
>   a ? b : c
>   a , b
> using the built-in meaning of the operators in these expressions
> there is a sequence point after the evaluation of the first expression.
>
> Thus, no undefined behavior, and the results are well defined.

Given the expression I _thought_ I was talking about, which would be:

x = (4, x++, x++);

there's no sequence point between the right hand side of the
assignment and the left hand side.  Unfortunately, I wasn't thinking
about the fact that the precedence of assignment is higher than that
of the comma operator, so I wasn't talking about the expression I
thought I was...

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


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

David Goh wrote:

> That can lead to some fairly serious kinds of unnoticed breakage, if you
> have classes with ++ operators or similar which perform ++ operations on
> (eg) integral members...
>
> Suddenly:
>
>    x++, x++;
>
> *isn't* defined behaviour.  Urgh.

Not very scary

It's one defined behaviour in a set of two. If ++
does increment *this, then the final behaviour is
the same as x += 2.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
>
> In article <MPG.1014b14d9a8af0e4989bb2@news.rmi.net>,
>   jcoffin@taeus.com (Jerry Coffin) wrote:
> > In article <6oeehg$5ba$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> > says...
> >
> > [ ... ]
> >
> > > > > int x =0;
> > > > > x=4,x++,x++;
> > > >
> From the FDIS, 1.8/18:
> In the evaluation of each of the expressions
>   a && b
>   a || b
>   a ? b : c
>   a , b
> using the built-in meaning of the operators in these expressions
> there is a sequence point after the evaluation of the first expression.
>
> Thus, no undefined behavior, and the results are well defined.

Well, yes, but... if the precedence had been the way Jerry thought (it
took me a bit of time to convince myself that he had it wrong) he'd have
been right:

 x=(4,x++,x++);

This results in undefined behavior.

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

Valentin Bonnard wrote:
>
> David Goh wrote:
>
> > That can lead to some fairly serious kinds of unnoticed breakage, if you
> > have classes with ++ operators or similar which perform ++ operations on
> > (eg) integral members...
> >
> > Suddenly:
> >
> >    x++, x++;
> >
> > *isn't* defined behaviour.  Urgh.
>
> Not very scary
>
> It's one defined behaviour in a set of two. If ++
> does increment *this, then the final behaviour is
> the same as x += 2.

Seems to me that the problem is deeper than that. The comma in the
expression above looks like a comma operator, but it isn't really: it's
a call to a function that takes two arguments:

operator,(x++,x++);

 It modifies the same variable twice without an intervening sequence
point. This makes the effect of the code undefined.
 In actual practice there are three potential calling sequences,
equivalent to the following calls (assuming the arithmetic operators
have their usual meanings):

operator,(x,x);x+=2;
operator,(x,x+1);x+=2;
operator,(x+1,x);x+=2;

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

On Wed, 15 Jul 1998 18:59:39, James Kuyper <kuyper@wizard.net> wrote:
> borrowing ideas from APL is not.
> One of APL's main advantages is that it allows you to write very simple
> expressions that correspond to very complex but highly regular
> operations on multi-dimensional arrays. Since those operations are
> built-in features of the language, code that mainly involves such
> operations can be optimized as well as or even better than corresponding
> C code, despite the fact that APL is an interpreted language. C++
> operator overloads make it possible to obtain much the same advantage in
> compilable C++ code. valarray<> is the one-dimensional prototype for
> what could be done.

A lot of this was done in Algol68 but due to the unfortunate
restrictions
on defining new operators in C++, slicing and multidimensional arrays
are impossible with any concise notation.


Ken Walter

Remove .zamboni to reply
All the above is hearsay and the opinion of no one in particular
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>> The only "trick" I know of (in the negative sense -- is there any
>> other?) is it's misuse for index-like operators, since so many other
>> languages use () for indexing.  "Say it in code" -- if you want to
>> use an index, use operator[], not operator().

jkanze@otelo.ibmmail.com wrote:
> There is room for discussion on this point. According to Barton and
> Nackman, for example, [] is NOT the index operator, but a projection
> operator, precisely because the results are not a single element, but
> an array of one less dimension.  And using () for the index operator
> is not necessarily counter-intuitive, although it isn't defined that
> way on the built-in types.

Operator[] is a "projection" operator *unless* it's overloaded,
in which case it could be anything (and could return anything).
Operator[] is simply another binary operator.  And that's the basic
problem with opererator overloading - it can change the meaning of
an operator to mean something entirely unobvious to the maintainer
of the code.  You stare at an expression like 'i++' over and over
until you realize that '++' doesn't mean "increment", and viola,
there's the bug you were looking for.  Overloading has given us
two standard meanings for '<<' and '()' where there was only one
before.

It is, at the same time, both a strength and weakness of C++ that
operators can have user-defined meanings.  A simple expression
like 'a=b+c' no longer has an "obvious" meaning like it does
in C.  It could mean "add matrix b to matrix c and assign the
result to matrix a" - that's a good use of overloading.  Or it
could mean "reformat the drive" - that's a bad use.

A good principle about operator overloading is: "Use it very
carefully and very sparingly."


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

In article <35ACC066.794B@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> AllanW@my-dejanews.com wrote:
> > C++ can borrow good ideas from other languages.  But in general,
> > trying to make C++ "look" more like some other language is a very
> > bad idea.
>
> I agree; making C++ look like APL would be a bad idea. However,
> borrowing ideas from APL is not.
> One of APL's main advantages is that it allows you to write very simple
> expressions that correspond to very complex but highly regular
> operations on multi-dimensional arrays. Since those operations are
> built-in features of the language, code that mainly involves such
> operations can be optimized as well as or even better than corresponding
> C code, despite the fact that APL is an interpreted language. C++
> operator overloads make it possible to obtain much the same advantage in
> compilable C++ code. valarray<> is the one-dimensional prototype for
> what could be done.

I think you may have a valid proposal for the next C++ standard.  (It's
probably too late for the current one.)  Fortunately, this would not
require an alteration to the language itself; instead, this would be a
new template member in the library.

For now, I suggest that you write the templates yourself, and then
make them publicly available shareware or freeware.  That will solve
most of the problems right away, because if they are well-written you
will be able to use them on any standard C++ compiler.

If you present them to the next standards committee for free, in a
form that should work on any standard C++ compiler, and if you
convince the committee members that the classes are widely useful
to a broad spectrum of users, then there is already precedent for
them to agree to adopt them into the standard.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

In article <6oifhh$lau$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
> In article <6ogp49$9b5$1@nnrp1.dejanews.com>,
>   AllanW@my-dejanews.com wrote:
> > [[ There's already precedent for using an operator in a completely new
> > way for certain class types -- operator<< and operator>>.  Which, in
> > my opinion, was a mistake -- these operations should have used a new
> > operator that didn't exist in C.  I wouldn't advocate switching to
> > that now, of course, but I hope we can limit this type of thing in
> > the future. ]]
>
> Agreed.  Who knows what crazy overloads might be invented, like ++ to
> advance through a linked list:-).

Which is conceptually the same as incrementing a pointer to an array.
As such, this would nicely and usefully mimic the built-in operator.

Oh, but the trailing :-) means that you were just kidding.

...Perhaps that would be useful notation in some future
version of standard C++.

    vector<int>::iterator i = vec.end();
    (*++i)=5;  :-)

The :-) would mean that we should NOT increment I and then use
it to store 5...

...nah, never mind.  Colon's been overloaded enough, and the
mismatched parens would be a real pain.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

AllanW@my-dejanews.com wrote:
>
> In article <35ACC066.794B@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > AllanW@my-dejanews.com wrote:
> > > C++ can borrow good ideas from other languages.  But in general,
> > > trying to make C++ "look" more like some other language is a very
> > > bad idea.
> >
> > I agree; making C++ look like APL would be a bad idea. However,
> > borrowing ideas from APL is not.
> > One of APL's main advantages is that it allows you to write very simple
> > expressions that correspond to very complex but highly regular
> > operations on multi-dimensional arrays. Since those operations are
> > built-in features of the language, code that mainly involves such
> > operations can be optimized as well as or even better than corresponding
> > C code, despite the fact that APL is an interpreted language. C++
> > operator overloads make it possible to obtain much the same advantage in
> > compilable C++ code. valarray<> is the one-dimensional prototype for
> > what could be done.
>
> I think you may have a valid proposal for the next C++ standard.  (It's
> probably too late for the current one.)  Fortunately, this would not

It most certainly is!

> require an alteration to the language itself; instead, this would be a
> new template member in the library.
>
> For now, I suggest that you write the templates yourself, and then
> make them publicly available shareware or freeware.  That will solve
> most of the problems right away, because if they are well-written you
> will be able to use them on any standard C++ compiler.
>
> If you present them to the next standards committee for free, in a
> form that should work on any standard C++ compiler, and if you
> convince the committee members that the classes are widely useful
> to a broad spectrum of users, then there is already precedent for
> them to agree to adopt them into the standard.

I plan to write just such a set of templates as soon as a strictly
conforming decent quality implementation of the new standard is
available at a reasonable price for my hardware. In fact, I have a
full-fledged differential geometry package planned. However, the
intended uses are fairly specialized; I wouldn't dream of suggesting
that it be made part of the STL. I was merely commenting on the more
general issue of the legitimate uses of operator overloading.


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

In article <35ADFE8A.C5BE2158@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> Valentin Bonnard wrote:
> >
> > David Goh wrote:
> >
> > > That can lead to some fairly serious kinds of unnoticed breakage, i=
f you
> > > have classes with ++ operators or similar which perform ++ operatio=
ns on
> > > (eg) integral members...
> > >
> > > Suddenly:
> > >
> > >    x++, x++;
> > >
> > > *isn't* defined behaviour.  Urgh.
> >
> > Not very scary
> >
> > It's one defined behaviour in a set of two. If ++
> > does increment *this, then the final behaviour is
> > the same as x +=3D 2.
>
> Seems to me that the problem is deeper than that. The comma in the
> expression above looks like a comma operator, but it isn't really: it's
> a call to a function that takes two arguments:
>
> operator,(x++,x++);
>
>  It modifies the same variable twice without an intervening sequence
> point. This makes the effect of the code undefined.

Not quite.  I think Valentin's point (which he could have stated clearer)
is that there is no type for which you can overload the comma operator
and the ++ operator is defined.  The result is that if operator, is
overloaded, and the above expression is legal, so is operator++.  Which
means that they are also functions; the logical equivalent of the express=
ion
is:  g(f(x),f(x)).  Which if the f's is called first is unspecified, but
there is no undefined behavior (because the call is a sequence point).

I'll admit it's a subtle point, and easily missed.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 14 Jul 1998 23:30:41 GMT, AllanW@my-dejanews.com wrote:

>
>Getting back to this specific case:  instead of using operator, to
>allow creation of a set, consider this:
>    template<class T>std::set<T>MakeSet(int num,...) {
>        std::set<T> s;
>        va_list v;
>        va_start(v,num);
>        while (num--)
>            s.insert(va_arg(v, T));
>        return s;
>    }
>This is not only easier to read and maintain (IMHO) than the
>comma-seperator overload, it's also more efficient, since it copies
>the set 1 or 2 times instead of N*(N-1)+1 times.  And yet usage is
>quite similar:
>    std::set<int> s(MakeSet<int>(5, 1,3,5,7,9));
>(If I had designed this explicitly for set<int>, instead of for any
>set<T>, then I would have omitted the argument count, instead using
>a trailing 0 value.)
>

Some annotations:
1. The VA-version is *not* equal to the overloaded operator version.
Consider
 s = 1, 2, 3. 0, f();
and
 s.set( 6, 1, 2, 3.0, f() );

where f is assumed to return something that can be converted to int.

The latter is wrong for at least three reasons. BUT IT COMPILES, and
that's why I usually fire people that write VA-functions for things
like that (I personally are against shooting them because they might
go and work for the competition and spoil *their* code - and that's
good for us).

2. The operator version is more efficient than the VA-version, because
it does not need to parse the argument list at runtime. If you use an
inline function, it (nearly) boils down to
 s.insert( 1 );
 s.insert( 2 );
 ...
 s.insert( f() );

Since the operator function returns a reference, no copying of s takes
place.

3. I personally do not use operator , but operator <<, and I write

 SomeCOntainer sc;
 sc << 1 << 2 << 3 << 4;

This makes clear what happens: The values "flow into the container".


------------------------------------------------
Martin Aupperle 1xx754.273x@compuserve.com
(replace x with 0 - fight spamming)
------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

I was wondering what was the purpose of having the "," operator used as
a separator for expressions.

In the the C++ grammar [Stroustrup 3rd edition] there is the rule
expression stated as follow:

expression:
 assignment-expression
 expression , assignment-expression

Clearly the operator "," is used as a separator between expressions.
There is already the ";" which is used to separate statements and a
statement can be an expression. So is there a reason for having a
separator for statements and a separator for expressions?
It probably comes from the C heritage, but I still don't understand the
rationale.

I mean the following two fragments mean the same-thing:

1.
int x =0;
x=4,x++,x++;

2.
int x =0;
x=4;x++;x++;

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

KNAPEN, GREGORY wrote:
> I was wondering what was the purpose of having the "," operator used
> as a separator for expressions.
>
> Clearly the operator "," is used as a separator between expressions.
> There is already the ";" which is used to separate statements and a
> statement can be an expression. So is there a reason for having a
> separator for statements and a separator for expressions?
> It probably comes from the C heritage, but I still don't understand
> the rationale.

Yes, it does come from C.  It allows you to do things like:

    for (i = 0, j = 1;  i < MAX;  i++, j += 2) ...
              ^                      ^
    while (c = getc(), c != EOF) ...
                     ^

You can't simply replace the ',' operator with ';', especially in
statements like those above.  And not having a ',' operator makes
coding those statements more difficult.

Arguably, the syntax of C/C++ *could* have been designed to do the
same thing with a different syntax, such as employing parenthesized
expressions with ';' separators, such as:

    for ((i = 0; j = 1);  i < MAX;  (i++; j += 2)) ...
               ^                        ^
    while ((c = getc(); c != EOF)) ...
                      ^

But they (i.e., Dennis Ritchie) didn't do this.  Consider it either
historical accident or the desire to be readable by design.  It's
really not so bad, as long as you don't abuse it.

Allowing the ',' operator to be overloaded in C++, on the other
hand...

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

KNAPEN, GREGORY wrote:
>
> Hi,
>
> I was wondering what was the purpose of having the "," operator used as
> a separator for expressions.
>
> In the the C++ grammar [Stroustrup 3rd edition] there is the rule
> expression stated as follow:
>
> expression:
>         assignment-expression
>         expression , assignment-expression
>
> Clearly the operator "," is used as a separator between expressions.
> There is already the ";" which is used to separate statements and a
> statement can be an expression. So is there a reason for having a
> separator for statements and a separator for expressions?
> It probably comes from the C heritage, but I still don't understand the
> rationale.
>
> I mean the following two fragments mean the same-thing:

Wrong. The value of a ',' expression is the value of the second
assignement expression.

> 1.
> int x =0;
> x=4,x++,x++;

x ends up with a value of 1.

> 2.
> int x =0;
> x=4;x++;x++;

x ends up with a value of 4.

The ',' operator is mainly useful in situations where you want to have
two or more statements executed in a situation where only one expression
is allowed. For example:

int i;
unsigned mask;

for(i=0, mask=1; i<16; i++, mask<<=1)
{
 // code using both i and mask.
}

However, I have seen it used most often to perform neat tricks in C
macros. Such uses should be far less necessary in C++ than in C.

On the other hand, having operator,() available for overloading has
produced a lot "interesting" tricks in C++. It can be used to catenate
containers together using APL-like syntax. It can be used to make a
function which actually takes only one argument look like it can handle
an arbitrarily long list of arguments. However, the sheer invisibility
of the ',' operator makes me leery of using these tricks.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AA535D.3A0D0D06@bell.ca>,
  "KNAPEN, GREGORY" <gregory.knapen@bell.ca> wrote:
> Hi,
>
> I was wondering what was the purpose of having the "," operator used as
> a separator for expressions.
The main purpose, I believe (I wasn't on the committee) was to allow
multiple side effects in for() expressions.  Such as:
    int i;
    char *p;
    for (i=0,p=addr; *p; ++i,++p)
        continue;
which calculates the equivalent of strlen(addr).  (I'm not advocating
this as good code, I'm just demonstrating the comma operator.)

> In the the C++ grammar [Stroustrup 3rd edition] there is the rule
> expression stated as follow:
>
> expression:
>  assignment-expression
>  expression , assignment-expression
>
> Clearly the operator "," is used as a separator between expressions.
Yes, clearly.

> There is already the ";" which is used to separate statements and a
> statement can be an expression. So is there a reason for having a
> separator for statements and a separator for expressions?
An expression can be used anywhere a statement is needed, but the
converse is not true.  The example above wouldn't work without the
comma operator, because the for() keyword expects three expressions.
I hope you can see why it would be impossible for the compiler to
understand your intent if you did this:
    for (i=0;p=addr; *p; ++i;++p)
This has five expressions (or five statements) between the parenthesis.
But which one is the one that tests when the loop is complete?

> It probably comes from the C heritage, but I still don't understand the
> rationale.
Yes.  I think I've shown why C did it; C++ does it the same way.

> I mean the following two fragments mean the same-thing:
>
> 1.
> int x =0;
> x=4,x++,x++;
>
> 2.
> int x =0;
> x=4;x++;x++;
Yes, they are.  There are nearly infinite more equivalent examples.
Personally, I like
    int x=6; // But add a comment here to say what x is, and why 6 is correct

You've shown that the comma operator isn't needed in expression
statements (although it certainly IS needed in other statements),
but you haven't shown the real problem with the operator.  The big
problem is it's UNINTENDED use.  For instance, this compiles with
no problems at all:
    char letters[5][5] = {
        { 'A', 'B', 'C', 'D', '\0' },
        { 'D', 'E', 'F', 'G', '\0' },
        { 'H', 'I', 'J', 'K', '\0' },
        { 'L', 'M', 'N', 'O', '\0' },
        { 'P', 'Q', 'R', 'S', '\0' } };
    std::cout << letters[1,1] << std::endl;
The programmer may have meant to print the letter E, but instead
it displays DEFG, because instead of the expression
    letters[1][1]
we have the expression
    letters[1,1]
which is equivalent to the expression
    letters[1]
which is equivalent to the second row of characters.  Some compilers
may warn about using the comma operator in an expression statement, or
at least in an index expression, but many don't (including the one I
use, darn it!).

Does anyone have a C++ "lint" program?  Does it catch this error?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AA8D83.59E2@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> KNAPEN, GREGORY wrote:
[snip]
> > I mean the following two fragments mean the same-thing:
>
> Wrong.
No, he was right.

> The value of a ',' expression is the value of the second
> assignement expression.
True.  But the result of the whole expression is thrown away.

>
> > 1.
> > int x =0;
> > x=4,x++,x++;
>
> x ends up with a value of 1.
Sorry, no.  The first sub-expression modifies x to have the value 4.
This result is discarded as the comma operator turns to the second
sub-expression.  This increments the value in x to the value 5, and
returns the value 4 to the sub-expression.  But this value 4 is also
discarded as we turn to the final sub-expression.  Once again, the
value in x is incremented (this time to 6), and the old value of x
(5) returned as the result.  The comma operator's result is 5, so the
expression statement's result is 5.  This result is promptly discarded.

Did you even try this?  Compile the above, and add std::cout<<x at the
end.  If you see 1 there is something seriously wrong.

> > 2.
> > int x =0;
> > x=4;x++;x++;
>
> x ends up with a value of 4.
Again, no.  The first expression statement modifies x to have the
value 4.  This result is discarded.  The second expression statement
increments the value in x to the value 5, and returns the old value 4
as the result of the whole expression.  But this value 4 is also
discarded as we turn to the final expression statement.  Once again,
the value in x is incremented (this time to 6), and the old value of
x (5) returned as the expression result.  Once again, this result is
promptly discarded.

Remember that C is not line- or position-dependant.  The above is
completely equivalent to
    int x =0;
    x=4;
    x++;
    x++;
except that in Gregory Knapen's example the last three statements
were all on one line.

> The ',' operator is mainly useful in situations where you want to have
> two or more statements executed in a situation where only one expression
> is allowed.
True.  Both expressions are evaluated, and the result of the overall
expression is the result of the last sub-expression.  But that result
isn't used unless the expression is used.  That is, your comments would
be closer to the mark (but still wrong) if Mr. Knapen had written
    y=(x=4,x++,x++);
because this does something with the comma expression's return value
(in particular, it assigns it to y).  But y is neither 1 nor 4, it's 5.

> However, I have seen it used most often to perform neat tricks in C
> macros. Such uses should be far less necessary in C++ than in C.
True.

> On the other hand, having operator,() available for overloading has
> produced a lot "interesting" tricks in C++.
"Tricks" that weren't around in C?  Like what?

> It can be used to catenate
> containers together using APL-like syntax.
Can you demonstrate?

> It can be used to make a
> function which actually takes only one argument look like it can handle
> an arbitrarily long list of arguments.
No, that isn't so.
    void one_arg(int i);
    one_arg(10, 20, 30, 40); // Error
This is illegal because it has four arguments.
    one_arg((10, 20, 30, 40)); // Ok
This is legal because it has one argument, the number 40.  But the
extra parens don't allow it to "look like" anything.  In any case
this isn't generally useful (because the first three "arguments"
are discarded).

> However, the sheer invisibility
> of the ',' operator makes me leery of using these tricks.
The comma operator is useful when it's useful, and not at other times.
The only problem I note with it is it's potential abuse in
index-expressions, since the syntax so nearly mimics that of so many
other languages (see my notes in a separate post).  Other than that,
it can be very useful in ANY place where multiple expressions must be
evaluated within one statement.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

In article <35AA535D.3A0D0D06@bell.ca>, gregory.knapen@bell.ca says...
> Hi,
>
> I was wondering what was the purpose of having the "," operator used as
> a separator for expressions.

The comma operator is used primarily in situations where you need to
have a single expression that does a number of different things.
Perhaps the classic example is in an for loop:

 for ( int x = 0, y=10; y!=0; x++, y--)
  Use x and y;

In this case, you can't just substitute a semicolon for any of the
commas, or you no longer have a syntactically valid for loop at all.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


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

In article <6oeehg$5ba$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
says...

[ ... ]

> > > int x =0;
> > > x=4,x++,x++;
> >
> > x ends up with a value of 1.
> Sorry, no.  The first sub-expression modifies x to have the value 4.
> This result is discarded as the comma operator turns to the second
> sub-expression.  This increments the value in x to the value 5, and
> returns the value 4 to the sub-expression.  But this value 4 is also
> discarded as we turn to the final sub-expression.  Once again, the
> value in x is incremented (this time to 6), and the old value of x
> (5) returned as the result.  The comma operator's result is 5, so the
> expression statement's result is 5.  This result is promptly discarded.
>
> Did you even try this?  Compile the above, and add std::cout<<x at the
> end.  If you see 1 there is something seriously wrong.

Not at all -- there's no sequence point between evaluation of the
right side and the left side of the expression.  Ignoring other parts
for the moment, the final result is the same as:

 x = x++;

which we all know gives undefined results unless x is of some type
that has = overloaded, so the argument has to be evaluated before the
operator is applied.  Since x is of type int, which can't have an
overloaded operator=, the results are undefined.  The extra sub-
expressions and comma operator have no real effect on the basic
problem -- they still don't force a sequence point between evaluating
the right and left sides of the assignment operator.

If you print out the result, any value can be printed out, and there's
NOTHING wrong at all.  You've invoked undefined behavior, so the
compiler can do anything within its power, and nothing is wrong with
it at all.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


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

AllanW@my-dejanews.com wrote:
>> It can be used to make a
>> function which actually takes only one argument look like it can handle
>> an arbitrarily long list of arguments.
>No, that isn't so.
>    void one_arg(int i);
>    one_arg(10, 20, 30, 40); // Error
>This is illegal because it has four arguments.
>    one_arg((10, 20, 30, 40)); // Ok
>This is legal because it has one argument, the number 40.  But the
>extra parens don't allow it to "look like" anything.  In any case
>this isn't generally useful (because the first three "arguments"
>are discarded).

You can get the effect the poster was talking about by overloading
operator,() to return a helper object, and writing one_arg to take one of
those.

I've not found it be a very useful technique, however... most of the time
(though not always) it means I should be passing a container. I find the
'syntactic sugar' more like 'syntactic molasses' -- it doesn't flow as
well and is harder to read.

Herb

---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp  2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com    Mississauga Ontario Canada L5K 2N6


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

In article <35AA535D.3A0D0D06@bell.ca>,
  "KNAPEN, GREGORY" <gregory.knapen@bell.ca> wrote:
> Hi,
>
> I was wondering what was the purpose of having the "," operator used as
> a separator for expressions.
>
> In the the C++ grammar [Stroustrup 3rd edition] there is the rule
> expression stated as follow:
>
> expression:
>  assignment-expression
>  expression , assignment-expression
>
> Clearly the operator "," is used as a separator between expressions.

In this context, "," is an operator within a single expression, and not
a separator between expressions.

> There is already the ";" which is used to separate statements and a
> statement can be an expression.

You have it backwards.  An expression can be a statement, but a statement
cannot be an expression.

> So is there a reason for having a
> separator for statements and a separator for expressions?

Yes, although it is irrelevant to the context you quote above.  The ","
can also be used to separate expressions, e.g. function arguements.  I
would find it quite confusing if the ";" were used here.

Of course, the fact that "," is sometimes an operator, and sometimes a
separator, is rather confusing in its own right.  In practice, however,
I simply never use it as an operator, and the problem is solved.

You might want to consider the following example:

    f( a , b ) ;                      // "," is separator, two arguments
    f( (a , b) ) ;                    // "," is operator, one argument

> It probably comes from the C heritage, but I still don't understand the
> rationale.
>
> I mean the following two fragments mean the same-thing:
>
> 1.
> int x =0;
> x=4,x++,x++;
>
> 2.
> int x =0;
> x=4;x++;x++;

They are for the given expressions.  Change int to a user defined type,
however, and there are two potential differences:

1. In the first, any temporaries generated by the expression stay around
until the final ";".  In the second, the temporaries are destructed at each
of the ";".

2. Operator "," can be overloaded for user defined types, so the first
expression might mean something completely different.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

In article <6oeehg$5ba$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:

> > On the other hand, having operator,() available for overloading has
> > produced a lot "interesting" tricks in C++.
> "Tricks" that weren't around in C?  Like what?

Obviously, if they involve operator overloading.

> > It can be used to catenate
> > containers together using APL-like syntax.
> Can you demonstrate?

I got the following from Paul Lucas:

    Set< int >&
    operator,( Set< int >& s , int i )
    {
        s.insert( i ) ;
        return s ;
    }

This allows you to write things like:

    Set< int >         s ;
    s = 1 , 3 , 5 , 7 , 9 ;

(Personally, this is a bit too subtle for my tastes, but it works.  Provided
you provide the necessary set<int>::operator=( int ) as well, of course.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

In article <35AA8D83.59E2@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> KNAPEN, GREGORY wrote:
> >
> > 1.
> > int x =3D0;
> > x=3D4,x++,x++;
>
> x ends up with a value of 1.

No. X ends up with a value of 6.  The results of the first two sub-expressions
are ignored, but the side effects (assignment, incrementation) must still
take place.  Also, since the comma operator is a sequence point, this
is well defined.

> > 2.
> > int x =3D0;
> > x=3D4;x++;x++;
>
> x ends up with a value of 4.

No. X ends up with a value of 6.  Where do you get the 4 from?

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

Jerry Coffin wrote:
>
>
> Not at all -- there's no sequence point between evaluation of the
> right side and the left side of the expression.  Ignoring other parts
> for the moment, the final result is the same as:
>
>         x = x++;

 Nope, you've got your precedences inverted here. The comma operator is
the only operator with lower precedence than assignment.

expression:
 assignment-expression
 expression ',' assignment-expression

That's why you can do things like a=3,b=4.
 So x=4,x++,x++ is parsed as (x=4),x++,x++ with a sequence point at each
comma. The value of the expression is 5, and x will end up with the
value 6.

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


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

>Clearly the operator "," is used as a separator between expressions.
>There is already the ";" which is used to separate statements and a
>statement can be an expression. So is there a reason for having a
>separator for statements and a separator for expressions?
>It probably comes from the C heritage, but I still don't understand the
>rationale.

// useful in for loops
for (int i=0,j=1; i<N; i++,j<<=1) ;

operator,(A,B) can be overloaded.  But if we do this, then we lose the
sequentialness of operator, -- namely A evaluated first, then B.  So
be careful when overloading operator,.  Sometimes overloading the
operator is a good idea; sometimes it is not.  The design principle
from Lakos is that user defined operators should mimic the builtin
operators.  There is an example on comp.lang.c++.moderated about
overloading operator,.

In "A,B,C", temporaries created in A won't be destroyed until C is
finished.  This is because the statement is thought of as one
expression.  So if the destructors of these temporary variables
have side effects -- for example, they may update local variables
of the function or write data to a file -- these effects will be
seen only be seen after C is finished.  Note that if the temps
created by A are not freed before executing B or C, our program will
use more run-time memory.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


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

Pete Becker <petebecker@acm.org> writes:

>Jerry Coffin wrote:
>>
>>
>> Not at all -- there's no sequence point between evaluation of the
>> right side and the left side of the expression.  Ignoring other parts
>> for the moment, the final result is the same as:
>>
>>         x = x++;

> Nope, you've got your precedences inverted here. The comma operator is
>the only operator with lower precedence than assignment.

And in addition, there is a sequence point at the comma in
a comma-expression, in C and in C++. Refer to the ISO C standard
6.3.17 "Comma operator", and C++ FDIS 5.18 "Comma operator".

--
Steve Clamage, stephen.clamage@sun.com


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