Re: on goto
tonydee <tony_in_da_uk@yahoo.co.uk> wrote:
On Apr 29, 8:51?pm, "Daniel T." <danie...@earthlink.net> wrote:
Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
On 28 Apr, 13:59, "Daniel T." <danie...@earthlink.net> wrote:
?SG <s.gesem...@gmail.com> wrote:
On 28 Apr., 11:02, Richard Heathfield wrote:
? Value_t* MyClass::findValue(const Value_t& value)
? {
? ? Value_t* result = 0;
? ? for(size_t xInd = 0; !result && xInd < data.size(); ++xInd)
? ? ? for(size_t yInd = 0; !result && yInd < data[xInd].size();
? ? ? ? ? ++yInd)
? ? ? ? for(size_t zInd = 0; !result && zInd < data[xInd]
[yInd].size();
? ? ? ? ? ? ++zInd)
? ? ? ? {
? ? ? ? ? if(data[xInd][yInd][zInd] == value)
? ? ? ? ? ? result = &data[xInd][yInd][zInd];
? ? ? ? }
? ? return result;
? }
I don't know about you but I like the first version better. It's more
concise. I find it easier to see what the loop's doing. Maybe it's
just me. I guess I'm used to these kinds of loops.
Since the sample code is obviously in c++, I would rather see something
like:
Iterator it = data.begin()
while(it != data.end() && *it != value)
? ?++it;
return it != data.end();
[snip]
The point of my example was to show that the problem with Juha's code
wasn't that it had multiple exits, but rather that it was at the wrong
level of abstraction and therefore seemed to need multiple exits.
Richard, removed the multiple exits without fixing the abstraction
problem and he ended up with a worse result.
That's a very insightful point, and in many ways good practice -
particularly if it prevents client code coupling to the implementation
or layout of your container. In this case though, the find function
might be a member of the container - inside the encapsulation - and
coupling quite acceptable. Further, say you want something just
marginally more complicated - like skipping every second value of
yInd: you can't do that with your iterator (the x/y/z boundaries are
lost), but it would be a trivial modification to the explicit loop.
Localisation, concision, directness and simplicity must be balanced
against abstraction - the latter is not always better. So, while I
agree an iterator may sometimes be good, I strongly disagree that the
explicitly nested loops were inherently at the wrong level of
abstraction, yielding a necessarily worse result.
In this case, the nested for loops were the wrong level, even if the
code was embedded in a member function. For your, rather arbitrary,
modification they may not be, but even there an iterator that knows how
to skip every second value of yInd might be more appropriate IMHO (if
such a construct is needed once for this container type, it probably is
needed in other places and duplicating the nested for loop construct is
even worse than putting it in once.
That said, finding examples where multiple returns are a good idea is
not hard, even with the code I presented something like this:
for (Iterator it = data.begin(); it != data.end(); ++it)
if (*it == value)
return true;
return false;
Here I have removed the extra conditional by introducing an extra
return. It's not how I would write it, but the above is quite acceptable
IMHO.
There is a general pattern here I think. When there are multiple exit
conditions to a loop (there is an && in the exit condition,) and we have
to be able to distinguish after the loop which condition caused it to
exit, then it may be appropriate to have multiple exits from the loop.
I'm just musing here, but what do you guys think?