Re: on goto
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(); ++xIn=
d)
for(size_t yInd = 0; !result && yInd < data[xInd].siz=
e();
++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 mo=
re
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 somethi=
ng
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.
Cheers,
Tony