Re: an algorithm with interruption in the middle
Seungbeom Kim wrote:
James Kanze wrote:
Actually, I would reject anything which didn't allow the use of
the switch.
A good point.
(Maybe we should be able to write "break for;" or "break while;"
to break out of a loop in a switch construct. :D)
Or maybe we should design a switch statement which wasn't so
primitive, and deprecate break altogether.
Or you could do something like this:
int key;
while ((key = pop()) != NONE) { /* ... */ }
which prevents you from "initialization at declaration"
and leaves key in scope after the loop, though..
Big deal. Unless the function is excessively complicated, there
won't be any significant code after the loop anyway. More
bothersome is the fact that it requires declaring the key
without an initializer.
Yes it is, but I (or we) have learned to live with it. The declaration
and the first assignment is very close to each other, anyway, so the
chances of confusion is minimal.
It didn't say it was a killer. Only that it was a more
important point than the fact that the variable was still in
scope after the loop.
Moreover, it's so common an idiom in reading an input of an unspecified
length:
string name;
while (cin >> name) { /* ... */ }
that I don't see it as a big problem.
Agreed. In the case of input, it's hard to avoid.
(Of course you can get around this
by writing something like:
template <typename T>
struct retval
{
bool success;
T value;
operator bool() const { return success; }
};
template <typename T>
retval<T> read(std::istream& is)
{
retval<T> r;
r.success = is >> r.value;
return r;
}
while (retval<string> name = read<string>(cin)) {
/* use name.value */
}
but I wouldn't go that far.)
You could use the Barton and Nackman Fallible---I've even
extended it to support error codes on failure. But I agree,
somehow it just doesn't feel right.
In the end, there is a lot to be said for using the standard
idiom. Even if it isn't what you would do if you were starting
from scratch, the fact that it is the standard idiom is a
powerful argument. Do anything else, and the first thing the
reader will do is ask why.
If NONE has a value which converts implicitly to false, you can
simply write:
while ( int key = pop() ) {
switch ( key ) {
// ...
}
}
And be done with it. I'm not sure I like this too much either,
though. Burying a declaration in a control flow statement is
fine for obfuscation, but in this case, doesn't seem to buy you
anything else.
Not only for obfuscation; I would say it's the cleanest solution in this
case, and in many others, including I/O.
Declaring a variable in a control flow statement is obfuscation.
If the alternatives are even worse, you live with it, but to
tell the truth, I've yet to see the case.
The main restriction is that the declared variable can be
compared only to zero, so see my proposal in another posting..
:)
Certainly, if you're going to do it, you want to do it right,
and not have just a few special cases.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]