Does this program make any sense?

[Daniel T.]

It's ugly.

Eye of the beholder, and all that - it looks fine to me ...

It would be better written as

if (condition) {
expression1;
expression2;
}

... whereas /that/ looks ugly to me [always assuming, of course, that
the expressions will fit comfortably as written].

The comma operator can be useful because it can be used in a larger
expression expression

`E1, E2` is larger than either of `E1` and `E2`, but I don't see why
that matters; the comma operator is useful because it can /combine/
expressions into bigger expressions ...

and because it yields the value of its right operand.

... and has a particularly simple evaluation rule.

Here it's not being used in a larger expression, and the
result is being thrown away.

The results of many expressions in C are thrown away, but that
doesn't make it wrong to use them as the then-part of an if-statement.

I was hoping for something more concrete than "it's ugly". Otherwise
it's just a discussion about style, and we can all pick our own.

*Just* a discussion about style? "It compiles" is not the sole
justification for using a particular construct. If you disagree, try
maintaining some winners of the obfuscated code contest.

 

[Csaba]

Except for overloaded operator , .

But you shouldn't do that. Overloading operator, is a dangerous idea (as
Scott Meyers would tell you) because it doesn't behave as the comma op for
built-in types: the built-in guarantees that the left operand is evaluated
before the right operand, whereas the overloaded operator, is a function,
and the order of eveluating arguments for a function is implementation-
defined (or worse).

 

[Kai-Uwe Bux]

But you shouldn't do that. Overloading operator, is a dangerous idea (as
Scott Meyers would tell you) because it doesn't behave as the comma op for
built-in types: the built-in guarantees that the left operand is evaluated
before the right operand, whereas the overloaded operator, is a function,
and the order of eveluating arguments for a function is implementation-
defined (or worse).

I beg to differ. One good thing about operator overloading is that you can
write code that closely resembles what you would read in text books on the
particular problem domain that you are dealing with. A prominent example of
this is boost::spirit. I overloads the comma-operator so that code can use
the EBNF to denote syntax rules. I cannot see anything wrong with that.


Best

Kai-Uwe Bux

 

[Csaba]

[snip] Overloading operator, is a dangerous idea

.... and as such should only be attempted by a trained professional

(as Scott Meyers
would tell you) because it doesn't behave as the comma op for
built-in types [snip]

I beg to differ. One good thing about operator overloading is that you
can write code that closely resembles what you would read in text
books on the particular problem domain that you are dealing with. A
prominent example of this is boost::spirit. It overloads the
comma-operator so that code can use the EBNF to denote syntax rules. I
cannot see anything wrong with that.

boost::spirit is strange enough so the user would not expect the comma
operator to behave as the builtin. For innocuous-looking classes it is
probably best avoided.