Re: Switch and case syntax restriction
Nevin :-] Liber wrote:
In article <b9PRi.11673$ZA.7630@newsb.telia.net>,
henke@henke37.cjb.net (Henrik Andersson) wrote:
It is not too hard to describe, I just did.
Not with nearly enough rigor to be a standards proposal.
Suppose I had the following class:
struct MyInt
{
operator int() const { return i + 1; }
bool operator==(int j) const { return i == j; }
int i;
};
//...
MyInt mi;
//...
switch (mi)
{
case 1:
DoSomething();
break;
case 2:
DoSomethingElse();
break;
}
What are the semantics of the above?
I will assume that you omitted the initialization of MyInt::i for
brevity and that it can be any valid int, not 1 in all cases or 2 in all
cases.
Same as:
if(mi==1) {
DoSomeThing();
} else if(mi==2) {
DoSomethingElse();
}
The operator(int) is not invoked, since the operator== got a specific
prototype for this case. This is different from how it currently would work!
What are the semantics if I make
any combination of the following changes:
1. Remove operator int from MyInt
Same as first example.
2. Remove operator== from MyInt
operator(int) would be invoked.
3. Make the case labels variables instead of constants
They would be read just before the comparison would be made
4. Make the case labels const variables
See 3., they are read just before comparing.
5. Allow operator== to modify the internal state of MyInt
It would do the modification, and it would last, assuming that the
compared expressions was going to last anyway.
6. Allow operator int to modify the internal state of MyInt
Assuming it is invoked at all, it would be allowed to do the modification.
Is it still 100% backwards compatible? I've only thought about this for
a few minutes; have I even covered all the possibilities yet?
Ok, there is one semantic change, if there is an operator(int) and a
matching operator==, previously the operator(int) would be invoked, but
after this change, operator== would be invoked instead. Good that you
brought up the conversion operators, since I didn't know about them.
I think that it would be a rather bad design if this semantic change
would effect any program. Also, this very issue would be similar in
effect to doing if(int==object), just that the operator== has priority
both before and after the change.
I must admit that I did not know of the conversation operators, but you
never stop learning.
Worse, it make all switch statements harder to read, as
one now has to understand the type of every label and variable being
switched upon before I know its semantics.
If people stopped doing crazy operator overloadings, the problem would
be void.
---
[ 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://www.comeaucomputing.com/csc/faq.html ]