Valentin Bonnard wrote:
>
> [Sorry for the math, but we are looking for the most
> natural notation for enum union and intersection]
>
> Christopher Eltschka wrote:
> >
> > Valentin Bonnard wrote:
> > >
> > > Christopher Eltschka wrote:
> > > >
> > > > Valentin Bonnard wrote:
> > >
> > > > > If you mean "or", use "or" which is spelled operator|
> > > > > in C++. (In case you don't know what x | y means.)
> > > >
> > > > Well, I guess the problem is that "or" means quite the
> > > > opposite of what one would think.
> > >
> > > I don't think so.
>
> > Also note that the komma in C++ already means "list" in a lot
> > of cases:
>
> As you already know, a list isn't a set.

As you already know, the usual notation for a (finite) set is
a list of its element, enclosed in curly braces.

> > Note that in any of the cases, they can be mixed with
> > expressions; in this case the order of evaluation is generally
> > unspecified (I'm not shure with variable lists, though),
>
> They are constructed in the specified order:
>
> int i = 3, j = i;
>
> > > In math union is written U, and or is V. Almost the same
> > > symbol... Why not do the same in CS ?
> >
> > Well, while formally, C++ "f1", ... are indeed the sets {f1}, ...,
> > it's not the way you think of them. You think of them as the
> > elements themselves. And while you may make an union of sets,
> > you don't make an union of elements.
> > In addition, set algebra is just a boolean algebra (the algebra
> > of bool is just a very special case), and for this, the usual math
> > notation is "+" for "or" and "*" for "and". Therefore the use of
> > "+" is absolutely justified.
>
> No it isn't. + means xor, not or, which has absorbant value (for
> example T, ie top, ie true in boolean algebre).

That's not the notation I know.

[...]

> > Note that Pascal uses + and * for set algebra as well.
>
> I don't care much about Pascal conventions. I care about C,
> C++ and math conventions.

But you could think about *why* Pascal uses + and *. Because it
contradicts math? I strongly doubt so.
And there are no C conventions about set algebra, because C does not
implement sets. You can emulate set algebra with arithmetic and/or
(indeed this is one of the most common uses of those).
C++ indeed has a notion of set, namely the STL set template.
This doesn't have operator| defined.

STL also contains the so-called bitset, but the std itself explains:

1 The header <bitset> defines a template class and several related func-
  tions  for representing and manipulating fixed-size sequences of bits.
                                           --------------------
Therefore bitset doesn't really define sets, but bit arrays.
(You can, however, use them instead of integral types to implement
sets.)
For bitset, there exist operator& and operator|, but that's not
astonishing given the semantics of bitsets, which are not really sets
(most notably, there's no notion of "x is in the set", but rather
an indexing operator[]. Also, there are operator>> and operator<<
which don't make sense on sets at all).

> > > Also x OR x is x, but x + x isn't x in general, so I think
> >
> > Not in general, but for boolean algebras in general.
>
> No it isn't. + is usually used for a group operation (well,
> not always (ordinals) but allmost always). In a group x + x
> can't be x except for 0.
>

As you say, not always. You mentioned ordinals; boolean algebras
are another example.

[...]
---
[ 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              ]

fvali <fvali@biotrack.com> writes:

> Can anyone please explain to me why and when some one would want to ever
> overload the comma operator (in a manner beneficial to the meaning and
> implementation of the UDT <i've seen an example where it was used as a
> subterfuge or rather to create an illusion, but not one where its use
> was deemed appropriate (if one can label it so)>), or was this feature
> just provided, because it was easier to provide, than not to provide?

The comma operators means evaluate the first argument, then
the second. If you were designing a class Function, and you
already have operator+ (Function,Function) (which is a function
whose result is the sum of the two results), you could also
overload the comma to give it the same meaning as in C, to
be able to write:

Function a, b;
(a, b) (); // equivalent to a (), b ()

You can also use the comma to have a 'list' notation:

        foo ((ListBeginner(), 4, 1, 5))

IntList  ListBeginner(); // return an empty list

IntList& IntList::operator, (int i)
{
     // append i to me
     return *this;
}

However the operator comma is rarely overloaded.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.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              ]

Mab wrote:
>
> point &operator,(const int &a, const int &b)
> {
>    return point(a, b);
> }

You can't do that because you can't overload unless at least one parameter is
of class type.

--

Ciao,
Paul


[ 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              ]

| > Can anyone please explain to me why and when some one would want to
| > ever overload the comma operator...
|
| The comma operators means evaluate the first argument, then
| the second.

However, *no user-defined comma operator can promise this semantics*!
The order of evaluation of the arguments to a user-defined comma
operator is no more or less constrained than the order of evaluation of
the arguments to any function:  It's arbitrary.

|             If you were designing a class Function, and you
| already have operator+ (Function,Function) (which is a function
| whose result is the sum of the two results), you could also
| overload the comma to give it the same meaning as in C, to
| be able to write:
|
| Function a, b;
| (a, b) (); // equivalent to a (), b ()

Not quite:  a(), b() guarantees that the evaluation of a() is complete
before b() is evaluated - something you can't guarantee.

In fact, this case is, in general, even worse.  In (a,b)(), you *are*
guaranteed that the evaluation of *both a and b* (and, of course, the
comma operator) is complete before operator() is invoked.  Now, if a and
b are just identifiers, when they are evaluated has no noticeable effect
on the program.  But they might not be.  Suppose a is f() and b is g(),
where f() and g() return appropriate object pointers or references.
Then:

 f()(), g()()

guarantees the following order of evaluation:

 f() f()() g() g()()

On the other hand

 (f(), g())()

guarantees one of the following orders of evaluation (assuming the
eventual operator() invokes its two arguments in the right order):

 f() g() [operator,] f()() g()()
 g() f() [operator,] f()() g()()

There is *no* legal order of evaluation common to the two expressions!

| You can also use the comma to have a 'list' notation:
|
|         foo ((ListBeginner(), 4, 1, 5))
|
| IntList  ListBeginner(); // return an empty list
|
| IntList& IntList::operator, (int i)
| {
|      // append i to me
|      return *this;
| }

In isolation, not an unreasonable usage.  It's very natural in many
programming languages, but not particularly natural in C (or C++),
because (a) as noted, an important part of the semantics of "," in C is
its imposition of a fixed order of evaluation; (b) the common under-
standing, to C/C++ users, that "," "returns its right argument.  So any
such definition gives you a "," with *very* different semantics from the
built-in ",".

Further, because the built-in "," works for *all* types, its all too
easy to write expressions that compile, but don't do what you expect.
If you have a list l, then (l,1) adds 1 to the end of l - but (1,l)
returns l unchanged.  (Yes, you can define an operator, *function* to
fix the latter, but it remains unnatural that (l,1) and (1,l) work, but
(1,2) simply returns 2.  Note that if you defined something like an
operator+(char*) in a string class, then s+"abc" would work - but
"abc"+s would be an error.  You'd have to define an appropriate global
operator+, just as in the (1,l) case - but at least the compiler would
*tell* you, rather than simply generating inappropriate code.)

| However the operator comma is rarely overloaded.

Yes, for the above reasons.  Similarly, && and || are rarely overloaded:
It's even harder to match their built-in semantics, since both arguments
to a user-defined && or || are always evaluated - i.e., user-defined
versions cannot have the built-in version's short-circuited evaluation.

Personally, I could imagine overloading && or || with a semantics
clearly entirely different from the normal boolean meaning.  "||" for
concatenation might make sense, for example - though "+" has come to be
standard for that use.  The low precedence of these operators is a
problem for many uses, though.  One place they *might* work reasonably
well would be to define patterns for string matching - && could be
sequential matching, || alternative matching.  Still, it would take some
experimentation to convince me that the notational advantages outweighed
the potential confusion.  I'd find this even more strongly the case for
",".
       -- Jerry


[ 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 Leichter wrote:
>
> | > Can anyone please explain to me why and when some one would want to
> | > ever overload the comma operator...
> |
> | The comma operators means evaluate the first argument, then
> | the second.
>
> However, *no user-defined comma operator can promise this semantics*!

Not directly, but as another level (functors), you can do
something similar.

> |             If you were designing a class Function, and you
> | already have operator+ (Function,Function) (which is a function
> | whose result is the sum of the two results), you could also
> | overload the comma to give it the same meaning as in C, to
> | be able to write:
> |
> | Function a, b;
> | (a, b) (); // equivalent to a (), b ()
>
> Not quite:  a(), b() guarantees that the evaluation of a() is complete
> before b() is evaluated - something you can't guarantee.

Yes I can, as long as the evaluation of a and b don't have side
effects:

class CommaFunction
{
    const Function& lhs, &rhs;
public:
    CommaFunction (const Function& lhs, const Function& rhs);
    void    operator()() {
        lhs ();
        rhs ();
    }
};

CommaFunction operator, (const Function& lhs, const Function& rhs)
{
    return CommaFunction (lhs, rhs);
}

> In fact, this case is, in general, even worse.  In (a,b)(), you *are*
> guaranteed that the evaluation of *both a and b* (and, of course, the
> comma operator) is complete before operator() is invoked.  Now, if a and
> b are just identifiers, when they are evaluated has no noticeable effect
> on the program.

That's the case in my example.

> But they might not be.  Suppose a is f() and b is g(),
> where f() and g() return appropriate object pointers or references.
> Then:
>
>         f()(), g()()
>
> guarantees the following order of evaluation:
>
>         f()     f()()   g()     g()()

Yes

> On the other hand
>
>         (f(), g())()
>
> guarantees one of the following orders of evaluation (assuming the
> eventual operator() invokes its two arguments in the right order):
>
>         f()     g()     [operator,]     f()()   g()()
>         g()     f()     [operator,]     f()()   g()()
>
> There is *no* legal order of evaluation common to the two expressions!

Correct

> | You can also use the comma to have a 'list' notation:
> |
> |         foo ((ListBeginner(), 4, 1, 5))
> |
> | IntList  ListBeginner(); // return an empty list
> |
> | IntList& IntList::operator, (int i)
> | {
> |      // append i to me
> |      return *this;
> | }
>
> In isolation, not an unreasonable usage.  It's very natural in many
> programming languages, but not particularly natural in C (or C++),
> because (a) as noted, an important part of the semantics of "," in C is
> its imposition of a fixed order of evaluation; (b) the common under-
> standing, to C/C++ users, that "," "returns its right argument.  So any
> such definition gives you a "," with *very* different semantics from the
> built-in ",".

Are you saying that it's an abuse ? I agree with you.

But with really long list, it's a resonnable abuse, and
in particular mimics the aggregate innitialisation syntax:

int x[] = {1, 2, 3, 4};

> Further, because the built-in "," works for *all* types, its all too
> easy to write expressions that compile, but don't do what you expect.
> If you have a list l, then (l,1) adds 1 to the end of l - but (1,l)
> returns l unchanged.

I would only use it for innitialisation, not mixed in expression (ie
I would use it in isolation).

> | However the operator comma is rarely overloaded.
>
> Yes, for the above reasons.  Similarly, && and || are rarely overloaded:
> It's even harder to match their built-in semantics, since both arguments
> to a user-defined && or || are always evaluated - i.e., user-defined
> versions cannot have the built-in version's short-circuited evaluation.

Thank you for posting this article.

I should have written this disclaimer myself. Indeed I don't
recommand to overload the comma, && and || operators in general.
(See my web pages:
http://pages.pratique.fr/~bonnardv/guide_cpp_e.html#class.operator.)
But I think that in some well-understoud cases, I makes sens.

I case of doupt, don't do it. If you are beginner with operator
overloading, don't do it.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.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              ]

Valentin Bonnard wrote:
>
> Christopher Eltschka wrote:
> >
> > Valentin Bonnard wrote:
>
> > > If you mean "or", use "or" which is spelled operator|
> > > in C++. (In case you don't know what x | y means.)
> >
> > Well, I guess the problem is that "or" means quite the
> > opposite of what one would think.
>
> I don't think so.
>
> > e_t models indeed a set,
> > and what you want is to have a set which contains f1 and
> > f2 and f3 and f4. The "or" is indeed an implementation
> > detail, because the set is implemented as bit field.
>
> The 'or' on the underlying type, yes, it's an implementation
> detail.
>
> > In Pascal, you would write it like this:
> ...
> > funct(a, b, c, [f1,f2,f3,f4], d, e, f);
> >
> > Note that again there's a komma syntax.
>
> Between square brackets. That's similar to the math notation:
> {f1, f3, f4}
>

In the overloaded-komma example, they were in parentheses:
(f1, f2, f4)
This also is similar to the math notation.
Omitting the parentheses is not possible, as then the f's would
be interpreted as different parameters to the function.

Also note that the komma in C++ already means "list" in a lot
of cases:

- argument lists: f(5, 7.0, "Hello World");
- initialiser lists: int x[] = { 1, 6, 4, 20 };
- variable lists: int x, y;
- enumerator lists: enum flags = { f1, f2, f3 };

Note that in any of the cases, they can be mixed with
expressions; in this case the order of evaluation is generally
unspecified (I'm not shure with variable lists, though),
and a komma operator expression _must_ use parentheses.
Therefore overloading the komma operator to represent lists
is not really against the C++ meaning of ",".

> > OTOH, Pascal doesn't have C(++)'s komma operator.
> >
> > To avoid the komma operator in C++, maybe the best solution
> > would be to use operator+:
> >
> > funct(a, b, c, f1+f2+f3+f4, f, e, f);
> >
> > This has the advantage that
> > - "+" has the connotation of "and" (thus it is better than "|")
> > - unlike "&", it won't be confused with bitwise operation
> > - If no value comes twice, the arithmetic "+" would indeed give
> >   the same result for the underlying numbers (although IMHO
> >   they should be considered an implementation detail)
>
> In math union is written U, and or is V. Almost the same
> symbol... Why not do the same in CS ?

Well, while formally, C++ "f1", ... are indeed the sets {f1}, ...,
it's not the way you think of them. You think of them as the
elements themselves. And while you may make an union of sets,
you don't make an union of elements.
In addition, set algebra is just a boolean algebra (the algebra
of bool is just a very special case), and for this, the usual math
notation is "+" for "or" and "*" for "and". Therefore the use of
"+" is absolutely justified.
Note that Pascal uses + and * for set algebra as well.

>
> Also x OR x is x, but x + x isn't x in general, so I think

Not in general, but for boolean algebras in general. Set algebra
*is* a boolean algebra. Also note that (using the implicit
conversions), with

bool f();
bool g();

the following two lines are identical:

{ bool a = f() & g(); bool b = f() | g(); cout << a << b << endl; }
{ bool a = f() * g(); bool b = f() + g(); cout << a << b << endl; }

If f() and g() don't have side effects, the && and || versions
give the same result as well.

> that operator| fits better.

I don't think so.


[ 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              ]

[Sorry for the math, but we are looking for the most
natural notation for enum union and intersection]

Christopher Eltschka wrote:
>
> Valentin Bonnard wrote:
> >
> > Christopher Eltschka wrote:
> > >
> > > Valentin Bonnard wrote:
> >
> > > > If you mean "or", use "or" which is spelled operator|
> > > > in C++. (In case you don't know what x | y means.)
> > >
> > > Well, I guess the problem is that "or" means quite the
> > > opposite of what one would think.
> >
> > I don't think so.

> Also note that the komma in C++ already means "list" in a lot
> of cases:

As you already know, a list isn't a set.

> Note that in any of the cases, they can be mixed with
> expressions; in this case the order of evaluation is generally
> unspecified (I'm not shure with variable lists, though),

They are constructed in the specified order:

int i = 3, j = i;

> > In math union is written U, and or is V. Almost the same
> > symbol... Why not do the same in CS ?
>
> Well, while formally, C++ "f1", ... are indeed the sets {f1}, ...,
> it's not the way you think of them. You think of them as the
> elements themselves. And while you may make an union of sets,
> you don't make an union of elements.
> In addition, set algebra is just a boolean algebra (the algebra
> of bool is just a very special case), and for this, the usual math
> notation is "+" for "or" and "*" for "and". Therefore the use of
> "+" is absolutely justified.

No it isn't. + means xor, not or, which has absorbant value (for
example T, ie top, ie true in boolean algebre).

You can define + and * in term of boolean operations:

a + b = a xor b = (a or b) and not (a and b)
a * b = a and b

or the other arround:

a or b = a + b + (a * b)
a and b = a * b

> Note that Pascal uses + and * for set algebra as well.

I don't care much about Pascal conventions. I care about C,
C++ and math conventions.

> > Also x OR x is x, but x + x isn't x in general, so I think
>
> Not in general, but for boolean algebras in general.

No it isn't. + is usually used for a group operation (well,
not always (ordinals) but allmost always). In a group x + x
can't be x except for 0.

> Set algebra *is* a boolean algebra.

I know that (precisely any set algebra (I mean U and
intersection) on P(A) (the set of parts of A) is a
boolean algebra).

[I am tied and there might be errors in the formullas in this
article]

--

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              ]

[Sorry for the difficult attributions. Entering the discussion late.]

This thread is drifting a (quite) bit; while it hasn't degenerated into
a flame war, it might be appropriate to set followups to clc++mod. It's
more about language usage than language definition, unless you want to
get into the "user-defined operator" argument.

Valentin Bonnard wrote:
> > > > > If you mean "or", use "or" which is spelled operator|
> > > > > in C++. (In case you don't know what x | y means.)

"Or" (and its equivalents) is also spelled "or" in standard C++, "U" in
set theory, "V" in relationship predicates, "+" in logic, and "and" in
everyday English usage. More later on the last.

In contrast, "|" is widely used in grammars and manuals to mean
"exclusive or."

Christopher Eltschka wrote:
> > > > Well, I guess the problem is that "or" means quite the
> > > > opposite of what one would think.

Valentin Bonnard wrote:
> > > I don't think so.

Programmers are often better at understanding logic than "normal" folks,
but not always. We often use "or" when we mean XOR but use "and" to mean
union or OR. We use the "either/or" construction to mean "exclusive or"
unambiguously. We also use "and" to mean logical AND in some contexts.
We use the ungainly "and/or" to mean OR unambiguously.

Also, the shorthand notations for "logic" in English are various
plus-like symbols (ampersand, plus, and a modified plus & squiggle that
my keyboard won't make), bars, and slashes, respectively. What these
really mean still usually depends on context, but usually:

   this+that+other: usually "and," meaning OR (union, all of)
   this/that/other: usually "or," but meaning any of AND, OR, XOR
   this | that | other: usually "or," almost definitely meaning XOR

Now, this shows that English usage of "logical" words is horribly
imprecise. It does, however, support Mr. Eltschka's recommendation to
use "+" for OR in combining enumerated flags. Even though English
speakers read "+" as "and," the meaning is the same as in logic:
inclusive or.

Therefore, I recommend defining operator+ for use as an "enumertor
combiner" in C++.

Christopher Eltschka wrote:
> > Also note that the komma in C++ already means "list" in a lot
> > of cases:

Valentin Bonnard wrote:
> As you already know, a list isn't a set.

If by "list" you mean "n-tuple," then a list is indeed a shorthand
notation for a set with certain properties. Almost everything is a set
of some kind, and a few languages have started from that "axiom."

Valentin Bonnard wrote:
> > > In math union is written U, and or is V. Almost the same
> > > symbol... Why not do the same in CS ?

Christopher Eltschka wrote:
> > In addition, set algebra is just a boolean algebra (the algebra
> > of bool is just a very special case), and for this, the usual math
> > notation is "+" for "or" and "*" for "and". Therefore the use of
> > "+" is absolutely justified.

Valentin Bonnard wrote:
> No it isn't. + means xor, not or, which has absorbant value (for
> example T, ie top, ie true in boolean algebre).

This is wrong, at least as logic is taught in American schools. We use:

    -  for not
    *  for and
    +  for or
   (+) for xor
   --> for implies
   <-- for implied by
   <-> for iff

More precisely, NOT is usually an overbar or "hooked" dash, AND is a dot
or variable catenation (for single-letter variables), XOR is a circled
plus sign, IMPLIES is a right-pointing arrow, IMPLIED-BY a left-pointing
arrow, and IFF (equivalent to) a double-headed arrow.

(French usage might be different, so "this is wrong" my not apply to Mr.
Bonnard's understanding of the usage.)

The symbols above show that it's probably useless to attempt to use an
entirely "natural" syntax for logical operations in C++. You could
probably get away with using >, <, == for IMPLIES, IMPLIED-BY, and IFF,
but XOR is a problem. There just isn't an operator with the right
precedence and appearance--OR & XOR are both "term" operators with the
same precedence. (I'm not sure of the precedence of the implication
functions.)

You could possibly solve this by allowing user-defined operators in C++,
but that's a different can of worms.

Christopher Eltschka wrote:
> > Note that Pascal uses + and * for set algebra as well.

Valentin Bonnard wrote:
> I don't care much about Pascal conventions. I care about C,
> C++ and math conventions.

Well, the Pascal usage is close to logic notation, and existing practice
in other languages is usually an acceptable rationale for a "new" usage.

Valentin Bonnard wrote:
> > > Also x OR x is x, but x + x isn't x in general, so I think
> >
Christopher Eltschka wrote:
> > Not in general, but for boolean algebras in general.
>
Valentin Bonnard wrote:
> No it isn't. + is usually used for a group operation (well,
> not always (ordinals) but allmost always). In a group x + x
> can't be x except for 0.

I'm not sure what you mean by group operations, unless you mean the
formal meaning of "group." In logic, however, both x + x == x and
x * x == x. They're important identities. (Also, x (+) x == 0).
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds


[ 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              ]

Christopher Eltschka wrote:
>
> Valentin Bonnard wrote:

> > If you mean "or", use "or" which is spelled operator|
> > in C++. (In case you don't know what x | y means.)
>
> Well, I guess the problem is that "or" means quite the
> opposite of what one would think.

I don't think so.

> e_t models indeed a set,
> and what you want is to have a set which contains f1 and
> f2 and f3 and f4. The "or" is indeed an implementation
> detail, because the set is implemented as bit field.

The 'or' on the underlying type, yes, it's an implementation
detail.

> In Pascal, you would write it like this:
...
> funct(a, b, c, [f1,f2,f3,f4], d, e, f);
>
> Note that again there's a komma syntax.

Between square brackets. That's similar to the math notation:
{f1, f3, f4}

> OTOH, Pascal doesn't have C(++)'s komma operator.
>
> To avoid the komma operator in C++, maybe the best solution
> would be to use operator+:
>
> funct(a, b, c, f1+f2+f3+f4, f, e, f);
>
> This has the advantage that
> - "+" has the connotation of "and" (thus it is better than "|")
> - unlike "&", it won't be confused with bitwise operation
> - If no value comes twice, the arithmetic "+" would indeed give
>   the same result for the underlying numbers (although IMHO
>   they should be considered an implementation detail)

In math union is written U, and or is V. Almost the same
symbol... Why not do the same in CS ?

Also x OR x is x, but x + x isn't x in general, so I think
that operator| fits better.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.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              ]

fvali wrote in message <34E9EFC3.661C@biotrack.com>...
>Can anyone please explain to me why and when some one would want to ever
>overload the comma operator (in a manner beneficial to the meaning and
>implementation of the UDT <i've seen an example where it was used as a
>subterfuge or rather to create an illusion, but not one where its use
>was deemed appropriate (if one can label it so)>), or was this feature
>just provided, because it was easier to provide, than not to provide?
>

I recently encountered a good use. It went something like this (I modified
it, the original would be to out of context to be a good example):

BoundQuery MyBoundQuery( &MyUnboundQuery,
    (
        QueryArg( "var1", "a_string_value"),
        QueryArg( "var2", 42)
    )
);

QueryArg is a class that acts as a linked list. The "," operator
concatenates the list items. This way a linked list can be formed and passed
to the constructor of MyBoundQuery in a simple and elegand way.

Martijn (mlievaar(at)orion(dot)nl
---
[ 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              ]

fvali wrote:
>
> Can anyone please explain to me why and when some one would want to ever
> overload the comma operator (in a manner beneficial to the meaning and
> implementation of the UDT <i've seen an example where it was used as a
> subterfuge or rather to create an illusion, but not one where its use
> was deemed appropriate (if one can label it so)>), or was this feature
> just provided, because it was easier to provide, than not to provide?
>
> -Thanks.

Just as a data point, I remember seeing
it used in at least one library to provide type safe combination of
enumerated bit flags, something like this:

typedef enum {
 f1 = 1,
 f2 = 2,
 f3 = 4,
 ...
} e_t;

inline e_t operator,(e_t a, e_t b)
{
 return static_cast<e_t>(
  static_cast<int>(a) |
  static_cast<int>(b));
}

So you can do this:

funct(a,b,c, (f1,f2,f3,f4...), d, e, f)

Whether or not this is subterfuge, I'm not sure, but
it does seem to increase type safety over other
methods.

-- Eric


[ 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              ]

fvali <fvali@biotrack.com> writes:
> Can anyone please explain to me why and when some one would want to ever
> overload the comma operator (in a manner beneficial to the meaning and
> implementation of the UDT <i've seen an example where it was used as a
> subterfuge or rather to create an illusion, but not one where its use
> was deemed appropriate (if one can label it so)>), or was this feature
> just provided, because it was easier to provide, than not to provide?

It forms a natural-looking list-building operator. Blitz++ uses it in
the construction of matrices, looking something like this:

 Matrix < 3, 3 > identity;
 identity = 1, 0, 0,
     0, 1, 0,
     0, 0, 1;

A simple version of such a class might be written as:

 template < typename T >
 struct Catenator
 {
  std::list < T > l;

  Catenator &operator=(const T &item)
  {
   l.clear();
   return *this, item;
  }

  Catenator &operator,(const T &item)
  {
   l.push_back(item);
   return *this;
  }
 };


[ 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              ]

Mab wrote:

> class point
> {
> protected:
>    int x,y;
> public:
>    point(int a, int b) {x = a; y = b};
> }
>
> point &operator,(const int &a, const int &b)
> {
>    return point(a, b);
> }
>
> Maybe???

No. You can't do that.

The point (a, b) syntax seems perfectly clear and adequate, BTW.
Why would you want annother one ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.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              ]

Eric Bloodworth wrote:

> typedef enum {
>         f1 = 1,
>         f2 = 2,
>         f3 = 4,
>         ...
> } e_t;
>
> inline e_t operator,(e_t a, e_t b)
> {
>         return static_cast<e_t>(
>                 static_cast<int>(a) |
>                 static_cast<int>(b));
> }
>
> So you can do this:
>
> funct(a,b,c, (f1,f2,f3,f4...), d, e, f)
>
> Whether or not this is subterfuge, I'm not sure, but
> it does seem to increase type safety over other
> methods.

It's completly silly. Operator overloading is there in
C++ to make things clear, not to win the IOC++CC.

a, b means evaluate a, throw the result away (no !
don't throw an exception ! hum... forget the result),
then evaluate b, give this result (the value of b).

If you mean "or", use "or" which is spelled operator|
in C++. (In case you don't know what x | y means.)

inline e_t operator|(e_t a, e_t b)
{
        return static_cast<e_t>(
                static_cast<int>(a) |
                static_cast<int>(b));
}

Also note that in your code the static_cast<int> aren't
necessary.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.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              ]

Valentin Bonnard wrote:
>
> Eric Bloodworth wrote:
>
> > typedef enum {
> >         f1 = 1,
> >         f2 = 2,
> >         f3 = 4,
> >         ...
> > } e_t;
> >
> > inline e_t operator,(e_t a, e_t b)
> > {
> >         return static_cast<e_t>(
> >                 static_cast<int>(a) |
> >                 static_cast<int>(b));
> > }
> >
> > So you can do this:
> >
> > funct(a,b,c, (f1,f2,f3,f4...), d, e, f)
> >
> > Whether or not this is subterfuge, I'm not sure, but
> > it does seem to increase type safety over other
> > methods.
>
> It's completly silly. Operator overloading is there in
> C++ to make things clear, not to win the IOC++CC.
>
> a, b means evaluate a, throw the result away (no !
> don't throw an exception ! hum... forget the result),
> then evaluate b, give this result (the value of b).
>
> If you mean "or", use "or" which is spelled operator|
> in C++. (In case you don't know what x | y means.)

Well, I guess the problem is that "or" means quite the
opposite of what one would think. e_t models indeed a set,
and what you want is to have a set which contains f1 and
f2 and f3 and f4. The "or" is indeed an implementation
detail, because the set is implemented as bit field.

In Pascal, you would write it like this:

type
  flags=(f1 ,f2 ,f3 ,f4 ,f5);
  e_t=set of flags;

and then could call

funct(a, b, c, [f1,f2,f3,f4], d, e, f);

Note that again there's a komma syntax.
OTOH, Pascal doesn't have C(++)'s komma operator.

To avoid the komma operator in C++, maybe the best solution
would be to use operator+:

funct(a, b, c, f1+f2+f3+f4, f, e, f);

This has the advantage that
- "+" has the connotation of "and" (thus it is better than "|")
- unlike "&", it won't be confused with bitwise operation
- If no value comes twice, the arithmetic "+" would indeed give
  the same result for the underlying numbers (although IMHO
  they should be considered an implementation detail)


[ 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              ]

Can anyone please explain to me why and when some one would want to ever
overload the comma operator (in a manner beneficial to the meaning and
implementation of the UDT <i've seen an example where it was used as a
subterfuge or rather to create an illusion, but not one where its use
was deemed appropriate (if one can label it so)>), or was this feature
just provided, because it was easier to provide, than not to provide?

-Thanks.
--
Biometric Applications & Technology
Faisal Vali - Software Engineer (B.A.T man)
---
[ 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 <34E9EFC3.661C@biotrack.com>, someone calling themselves fvali <fvali@biotrack.com> wrote:
>Can anyone please explain to me why and when some one would want to ever
>overload the comma operator (in a manner beneficial to the meaning and
>implementation of the UDT <i've seen an example where it was used as a
>subterfuge or rather to create an illusion, but not one where its use
>was deemed appropriate (if one can label it so)>), or was this feature
>just provided, because it was easier to provide, than not to provide?

This is just a guess, but what if you had something like:

class point
{
protected:
   int x,y;
public:
   point(int a, int b) {x = a; y = b};
}

point &operator,(const int &a, const int &b)
{
   return point(a, b);
}

Maybe???

|~\  /~| /~~| |~|   The .sig wears a ring of polymorph! --More--
|  \/  |/ / |_| |__ The .login hits! The .cshrc bites!
|      ' /| |_| | / ________________________________________________
| |\/|  /\  | |  /  Official member of STI:
| |  |_/  \_| | /           The Search for Terrestrial Intelligence!
=\|===========|/==========- The Mabster:  mhamilton@bunge.com.au -==
---
[ 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              ]