 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Andrei Alexandrescu
Guest
|
 Posted: Thu Jun 26, 2003 2:10 pm Post subject: Re: Reasons for single entry, single exit |
 |
|
"John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote
| Quote: | On 23 Jun 2003 21:51:24 -0400, [email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote:
I have tried to argue that SEME is preferable when it leads to
better code as measured by a number of common criteria, eg
modularity.
We do not agree on what that means. Does anyone else? You claim
that a statement which aborts a function is modular. That is a
new meaning for me.
|
It is one thing to abort, and a different thing to exit.
But even so. A statement that **aborts** a function (the throw
statement)
allows... modular error handling. How about that?
| Quote: | Else is valuable information or clutter.
Warts are great or clutter.
White space is good or clutter.
Identifiers with more than one character are clutter.
|
This method of constructing an argument is not, well, constructive. You
compare the argument at hand with some unrelated ones that create
disapproval.
| Quote: | Some claim that repitition aids understanding.
Never repeat the word return in a function. 
|
Ah, those maybe forgot one detail: repetition /of a sensical thing/ aids
understanding  ).
| Quote: | Such general rules often lead to SEME code.
Sorry, but it seems that those are names for opinions that you
hold rather than well defined and accepted rules. I suspect
that they are empty statements used to justify the SEME code
rather than produce it.
|
One thing that is worth remembering is that SEME includes SESE; it's
pure
inclusion, not partial overlapping or disjoint subsets. It's not that in
SEME everybody compulsively returns wherever there's the slightest
chance.
So basically it's a SESE programmer who needs to justify this dogma, not
the
SEME programmer. A programmer who has freed his mind of SESE will write
better code because he can write what a SESE programmer would write, and
can
choose not to write SESE in the overwhelming cases when SESE doesn't
have
any utility.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 2:14 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 25 Jun 2003 13:11:32 -0400, "Andrei Alexandrescu"
<SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:
| Quote: | "John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote in message
Nope. Consider that most code I see never has an exception. The
only
chance is out-of-memory and the system crashes the program with no
chance for it to throw. Exceptions do not exist. Adding them to
the
mix is not a justification for adding other abnormal control flows.
I guess that pretty much says it all. The majority of functions I
write call
into other functions (my own, library, others) that can throw
exceptions. I
expect my code to recover gracefully after an exception was thrown.
|
So what? I expect the same. RAII is good. That is not an excuse to
write unstructured mainline code. I see your major argument being that
since exceptions violate SESE it is acceptable to write everything that
way.
Using exceptions removes the error path from distorting the normal code.
This is inter function. Using SESE removes unstructured code from
distorting the normal code. This is intra function.
void find (int a[], int n, int t) throw (int) {
for (int x(0); x != n; ++ x)
if (a[x] == t)
throw x;
throw n;
}
I see your exceptions argument as an excuse not a reason. Excuses are
not convincing. There is no fruit on this path. Show comparative
goodness.
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 2:15 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 25 Jun 2003 13:15:02 -0400, "Andrei Alexandrescu"
<SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:
| Quote: | "John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote in message
news:tfeffvci7cbr56stkohharjfu75cclj7tq (AT) 4ax (DOT) com...
Let's change the spec a little.
Just to make sure that everyone knows we are playing games, lets
change the spec a little. Use iterators. The only choice for
not found is off-the-end. That solution will fit pointers with
no need for null and index with no need for -1. Why do you
want several solutions to one problem? Note that you have
fabricated a not found answer that is not in the parameters.
A magic number.
I believe the irony is misguided (and the tone of the whole post a bit
too
strident if you ask me),
|
Just to counter your exceptions noise.
| Quote: | because I believe the spec is entirely reasonable.
In particular, there are std::string functions that return -1 for "not
found".
|
No. They return string::npos which is way off the right end.
String::npos is not a magic number in the middle of the range which only
applies to signed numbers. It is a sentinel value defined within the
class.
| Quote: | Call them silly, but they respect a spec that is not "just to make
sure that everyone knows we are playing games".
|
With strings, my algorithms work with either size or npos. More noise?
| Quote: | Congratulations. You made a simple change in one line of the nice
function and satisfied the silly change of spec. There may be hope
for you yet.
No hope.
|
Consider this.
int find (int a[], int n, int t) {
return std::find(a, a + n, t) - a;
}
Nice? You want -1?
int find_with_magic (int a[], int n, int t) {
int x(find(a, n, t));
return x == n ? -1 : x;
}
Surely, you do not advocate writing a whole new version.
| Quote: | No. My objective was to show that SESE is simply not worth even
considering
when writing code because it brings no benefit.
|
That is a problem. Almost everyone else accepts SESE as a good idea
with some cases which may be better with SEME. You seem to claim that
SEME should always be used in preference to SESE.
| Quote: | There are algorithms that
are best expressed with multiple returns. For those, SESE is just
unneeded
contortions.
|
There seems to be a lack of examples. Contortion also seems to lack
a definition. "Anything I don't like", seems to be the working modle.
| Quote: | Since we are having fun, lets do that silly change of
spec right. The spec obviously wants n to act like -1;
so, let's do it.
int init (int n) {
return n ? 0 : -1;
}
int& inc (int& i, int n) {
return ++ i == n ? i = -1 : i;
}
int find (int a[], int n, int t) {
int x(init(n));
while (x != -1 && a[x] != t)
inc(x, n);
return x;
}
That SESE solution is really nice and very adaptable to silly
changes in spec.
What??? A three-function solution instead of the deserved four-liner?
Is
this a joke?
|
Actually, it is a static member of a template class. The init and inc
are policies used to customize the algorithm for almost anything.
| Quote: | Should we now play with binaray search in the form of lower_bound
since the other is mostly useless. It took 18 years of publication
before anyone got it right. We should be able to do better.
That would be an interesting challenge. It's unclear what SESE
proponents
could prove, because a programmer not bothered by SESE would write
SESE when
SESE is the clearer way to implement an algorithm, and SEME when SEME
is the
clearer way to implement an algorithm. Yessense.
|
The reason that it took 18 years was that early exit was attempted.
Once a simple SESE approach was taken, it just worked. A survey of
textbooks showed that most contained an incorrect version. Again,
early exits (sometimes poorly structured) and a questionable
specification. The textbook survey was 25 years after the published
correct version. I'm sure that we can both produce a correct version,
but I doubt that the code quickly attitude of SEME will produce one.
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Thu Jun 26, 2003 2:16 pm Post subject: Re: Reasons for single entry, single exit |
|
|
<kanze (AT) gabi-soft (DOT) fr> wrote
| Quote: | Doug Harrison <dsh (AT) mvps (DOT) org> wrote in message
news:<ae1ffvovsrdi1qiqcr6qltthgcuiilhhbs (AT) 4ax (DOT) com>...
Here, we have a very good example with Francis' read function, in
another thread. Suppose we change the code to use it:
for ( int item( read<int>(cin) ) ;
item != -1 ;
item = read<int>(cin) ) {
sum += item ;
}
Well, we've still repeated the call to "read<int>(cin)", I guess. If
this is a problem, do we also throw out all of the numeric code which
has more than one call to "sin(x)" ?
|
Huh? What does this have to do with the other?
| Quote: | The essential thing to understand here, I think, is that the first
part
of the for does NOT have the loop invariants as a pre-condition.
|
That's understood, but in no way I see it as essential. It's a "true but
uninteresting" fact.
What's essential here IMHO is one thing:
<-
Hard to get *any* clearer than that. If this simple truth is grasped, a
natural implementation would keep reading and testing together. This is
arguably not very syntactically nice in C++:
for (int item; (item = read<int>(cin)) != -1  {
sum += item ;
}
The "unniceness" stems from the particular fact that C++ doesn't allow
defining variables in arbitrary expressions. That, as you point out, is
just
a language thing. To make it crystal clear that it's just an obscure
little
language thing and not a matter of principle, if read<int> returned 0 on
EOF, the loop could be indeed written as (this is a feature added
relatively
recently):
while (int item = read<int>(cin)) {
sum += item ;
}
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 2:21 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 23 Jun 2003 15:26:08 -0400, Ed Avis <ed (AT) membled (DOT) com> wrote:
| Quote: | John Potter <jpotter (AT) falcon (DOT) lhup.edu> writes:
Indeed; all coding style questions are subjective. The only objective
measure is to take two identical programmers of equal skill, show one
of them a version of the code written in style A, show the other the
code in style B, and see which one is first to understand what the
code does.
But even there you have to choose code carefully; it would be very
easy to construct an example which shows that operator overloading
obfuscates programs, and just as easy to construct one showing it
clarifies them.
|
There is another problem which seems to show in reaearch. The way in
which the programmers usually code will influence the results. It is
really no surprise that the test case shown in the paper with novice
programmers given a novel control structure were successful using it.
Students are very good at making the current new thing work. They are
very bad at deciding which thing to use given more than one.
| Quote: | What I object to is an assertion that one style is automatically
better than the other, in all cases. I suggest that the burden of
proof lies with those who make such wide-reaching statements, rather
than those who think there could be different cases favouring
different coding styles.
|
I assert that SESE is a rule not that it is the best rule. It seems
that there are no SEME rules. It is not teachable and there is no
way to evaluate its use.
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Thu Jun 26, 2003 2:21 pm Post subject: Re: Reasons for single entry, single exit |
|
|
"John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote
| Quote: | Every time through this function, you declare and initialise a
variable
(pNew) that is only actually needed in one of the four
(nonexceptional)
pathways. I'd call that ugly.
Named return value optimization. It is just another name for the
return
value which must be created regardless of how the function is written.
Patterns.
|
And the point is?
ME code benefits of Unnamed Return Value Optimization (URVO) which, as
one
of my articles describes, is easier to implement and therefore more
widespread. Basically the compilers implementing NRVO are a subset of
those
implementing NRVO.
In general, absent very advanced optimization techniques (dead
assignment
elimination performed after inlining and alias analysis, oh joy), SE
code
will often be one initialization/assignment behind ME code, especially
when
returning nonprimitive types.
Another one for ME, yippie!
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 6:52 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 25 Jun 2003 16:27:49 -0400, [email]ivlenin (AT) gmx (DOT) co.uk[/email] (I V) wrote:
| Quote: | John Potter <jpotter (AT) falcon (DOT) lhup.edu> wrote
On 22 Jun 2003 20:06:52 -0400, Terje Sletteb
[email]tslettebo (AT) chello (DOT) no.nosp[/email]am> wrote:
void* realloc(void* p, size_t newSize)
{
return p == 0 ?
malloc(newSize) :
newSize == 0 ?
free(p),0 :
try_expand(p, newSize) ?
p :
get_new_chunk(p, newSize);
}
Yuk! We are on the same side and I can't read that. It lacks form.
Actually, I don't think you are on the same side: Terje's code above
seems to be in effect a 'translation' of the SEME code posted earlier
into a functional idiom.
|
No. We are on the same wavelength. He did not simply restructure the
code. He factored the problem case to two other functions. That comma
operator is nasty and actually produces a syntax error. I think that
Terje and I might agree to also factor it to, say, do_free. This
makes it possible to write SESE ?: code. A function that is a single
return statement is uncontestably SESE.
// Marginally acceptable
void* realloc (void* p, size_t newSize) {
if (p == 0) return malloc(newSize);
if (newSize == 0) return do_free(p);
if (try_expand(p, newSize)) return p;
return get_new_chunk(p, newSize);
}
// Better
void* realloc (void* p, size_t newSize) {
void* newP;
if (p == 0)
newP = malloc(newSize);
else if (newSize == 0)
newP = do_free(p);
else if (try_expand(p, newSize))
newP = p;
else
newP = get_new_chunk(p, newSize);
return newP;
}
// Best
void* realloc (void* p, size_t newSize) {
return p == 0 ? malloc(newSize)
: newSize == 0 ? do_free(p)
: try_expand(p, newSize) ? p
: get_new_chunk(p, newSize);
}
// Alternate
void* realloc (void* p, size_t newSize) {
return p == 0 ?
malloc(newSize)
: newSize == 0 ?
do_free(p)
: try_expand(p, newSize) ?
p
:
get_new_chunk(p, newSize);
}
I don't think this adds anything. My objection to Terje's code is
that it implies some nested structure rather than a case structure.
I think ?: becomes unreadable when nesting is required.
T& min3 (T& a, T& b, T& c) {
return b < a ?
c < b ?
c
:
b
:
c < a ?
c
:
a;
}
T& min3 (T& a, T& b, T& c) {
return b < a ? c < b ? c : b : c < a ? c : a;
}
Just say no!
T& min3 (T& a, T& b, T& c) {
return min(min(a, b), c);
}
The same objection for nested returns, but nobody wants limits.
| Quote: | Certainly, it has what I consider to be the
principle advantage of the SEME version of realloc over the SESE
version you posted, namely that it is more modular.
|
If by modular, you mean uses other functions, I agree.
| Quote: | As you read
through either the SEME or functional versions, you come to places
where you know you can stop paying attention to what has gone before;
at 'return malloc(newsize)' I know that the p == 0 case has been dealt
with, and I can promptly forget about the details of that case. With
your code, however, I have to keep the whole function in mind while
reading through it, for example in order to understand what is going
to happen to pNew.
|
Amusing that we have the same argument in reverse. I know that all
code is SESE and can read the else-if code knowing that the return
variable is assigned a value on each branch. Now that I have the
big picture, I may read any branch knowing that it is self contained.
The same is true for the ?: version of else-if. In the SEME version,
there is no big picture. Each branch must be examined in order to
determine if main line code is really executed.
| Quote: | Actually, it seems to me that in that respect SESE is very much like
goto - the meaning of parts of the function subtly depends on other
parts that may be quite distant. Now, this can happen in badly written
SEME functions as well, of course, but it seems unavoidable in
functions which have been specifically written to avoid multiple
exits. If that's correct, although SEME can be abused, SESE is
intrinsically obfustatory and so can never _not_ be abused.
|
Counter: In SEME code, the meaning of main line code subtly depends on
other aborts that may be quite distant.
I think that you might agree with my "best" evaluation above. The
relative rating of the other two does not really matter. What does
matter is that there are those who disagree with the "best" part.
They also disagree with the factorization which made the ?: possible.
Dave Harris has coined this "Ravioli" code because it produces too
many functions and the multiple returns are more modular. The SEME
advocates see no reason to factor or limit the number of nestings or
returns.
IMO, once the factorization is done, the ?: is best and the other
two are not worth discussion. Without the factorization, I prefer
the SESE version because it retains the form of the ?: version.
I want to see pictures not brush strokes.
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 6:53 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 25 Jun 2003 16:21:56 -0400, [email]thomas.hyer (AT) ubsw (DOT) com[/email] (Tom Hyer) wrote:
| Quote: | John Potter <jpotter (AT) falcon (DOT) lhup.edu> wrote
Restructuring things.
void* realloc (void* p, size_t newSize) {
void* pNew(0);
if (p == 0)
pNew = malloc(newSize);
else if (newSize == 0)
free(p);
else if (p == _expand(p, newSize))
pNew = p;
else {
pNew = malloc(newSize);
if (pNew != 0) {
memcpy(pNew, p, _msize(p));
free(p);
}
}
return pNew;
}
If you do not see the subjective beauty of the SESE forms, you
need new glasses. :-)
OK, I'll be the blind volunteer. Let us reason together.
If I am analyzing this function, I want to find out what it is
returning. In the SESE form, I scan to the bottom (as you say) and
see that it is returning pNew. Then I examine the function body for
statements which change pNew.
|
If SEME does not exist, I see that there is a variable which is assigned
a value on one of four branches of a case structure and returned. Now
I can examine the controls to determine the decision structure. Then I
can look at the self contained code on each branch to see what value is
assigned.
| Quote: | In the SEME form, I examine the function body for returns.
|
The whole thing. There is no structure. Of course not, it is
unstructured. In SESE, you scan the structure. In SEME you
search for structure.
| Quote: | Since
on most branches pNew is only written, not used, by this algorithm,
"pNew = " is the SESE substitute for "return". The SESE style puts an
extra step in the scanning process, slightly obfuscating the code, and
gains _nothing_.
|
Only structure.
| Quote: | In exchange, I guess that SESE _if used everywhere_ makes the
scanning process more mechanical -- go to the end, see what is
returned, then backtrack and see how it was made. In SEME you don't
know ab initio whether there's more than one exit. Whether this gain
is worth writing "pNew = " when I mean "return" is debatable.
|
If there were a structure that said each clearly visible branch will
return, I could agree. If factored to one liners, it makes little
difference and can be replaced by ?:. If not, SESE gives structure.
Thinking about your statements, I wonder if there might not be a
conflict of procedural and object oriented? Procedural code is
designed top down. Class hierarchies are designed bottom up. I
want to look at the left edge of the code to see the root of the
decision tree. Others want to look at the right side of the code to
see the leaves. Does that make any sense?
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 6:54 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 25 Jun 2003 13:09:43 -0400, "Andrei Alexandrescu"
<SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:
| Quote: | Your post rux. By the way, imho breaking from loops is a notch below
early
returns in terms of understandability of code. The function is a much
clearer and well-defined entity than a loop.
|
I might agree with this. No loop will ever be used except as the only
element of a function. There will be only one return in the loop. Now
that form of SEME is constrained to be harmless. Will you accept that
rule?
| Quote: | One more thought on SESE - it was better justified in the good ol'
days with
no destructors and no automatic memory management and no exceptions.
It was
extra effort, but it was justified because the alternative was "goto
exit;"
and such stuff. You needed to clean up after yourself before leaving a
function etc. But now, it's about time SESE goes to the recycle bin of
history.
|
Because one of the problems that structured programming solved has other
solutions today, we should accept that it is useless. Sorry, but
structured unstructure is still unstructured with all of its problems.
SESE provides structure. Unbridled SEME destroys structure. Limited
SEME might provide structure. I hear you advocating no structure. Is
that really your intent?
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Potter
Guest
|
| Posted: Thu Jun 26, 2003 6:54 pm Post subject: Re: Reasons for single entry, single exit |
|
|
On 23 Jun 2003 21:53:09 -0400, "Andrei Alexandrescu"
<SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:
| Quote: | Would it be better to have rules but not taste? )
|
If we accept the statement from Francis that humans have little
or no logic, they will never develope taste but might be useful
given rules.
Without that, rules can be followed but taste requires time to
developement.
John
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Jun 26, 2003 7:12 pm Post subject: Re: Reasons for single entry, single exit |
|
|
Francis Glassborow <francis.glassborow (AT) ntlworld (DOT) com> wrote
| Quote: | In message <nanffv0ng5g5o7cgej7mjpnfq1cgoct5rq (AT) 4ax (DOT) com>, Andrea
Griffini
[email]agriff (AT) tin (DOT) it[/email]> writes
Is there a reason for preferring "int x(0);" to "int x=0;" ?
The reason that I prefer it is that it provides consistency both with
UDTs that using more than one argument for initialisation and for
places where only this syntax is valid (ctor initialisers). It also
handles UDTs with explicit ctors. If you were starting from scratch
(i.e. had no prior knowledge of programming) would you prefer to learn
one way or two?
Of course there is the issue of accidentally declaring a function but
that has to be tackled at some time.
|
Not to mention the fact that, legal or not, some comilers don't like it
for certain types. (I've had problems with at least two different
compilers -- one for ints, and another for references.)
--
James Kanze GABI Software
mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter
Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45
16
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Jun 26, 2003 7:14 pm Post subject: Re: Reasons for single entry, single exit |
|
|
"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote
| Quote: | In news:d6652001.0306240211.c0d6466 (AT) posting (DOT) google.com,
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> wrote :
Doug Harrison <dsh (AT) mvps (DOT) org> wrote in message
news:<ae1ffvovsrdi1qiqcr6qltthgcuiilhhbs (AT) 4ax (DOT) com>...
John Potter wrote:
// An alternative classic
int item;
for (cin >> item; item != -1; cin >> item)
sum += item;
Bad classic. Suffers from code duplication. I can't be talked into
this one. :)
We recently had an interesting discussion about this in
fr.comp.lang.c++. It turns out that there isn't really code
duplication here, or rather, that the code duplication is
accidental. The important point is that you have a loop with for
parts: an initialization, a test, a body, and an update.
Accidentally, here, the code for the initialization and for the
update looks the same. When reasoning about the loop, however, it
is important to realize that the two parts do NOT share a common
pre-condition -- and thus, that one is likely to change without a
change in the other.
You make it sound like we (in fr.comp.lang.c++) came to the conclusion
that there is no code duplication in the example above. I don't think
that was the conclusion.
|
I don't think that there was a conclusion. I think that there was a
realization that there is more to the question than meets the eye.
There is also an undisputed fact that the constraints concerning what
you put in the first part of the for are different than those concerning
what you put in the last part. The constraint for the first part is the
post-condition: the variable item is initialized. If something happens
elsewhere in the code to ensure that it is initialized before reaching
the for, I can suppress the first part of the for. A critical
requirement for the third part is that I am making headway. When I
reach the third part, the variable item is initialized by definition.
But if I eliminate the third part, I won't get anywhere very fast.
Textual similarities do not mean duplication if the pre- and
post-conditions are different.
--
James Kanze GABI Software
mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter
Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45
16
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
George van den Driessche
Guest
|
| Posted: Thu Jun 26, 2003 7:15 pm Post subject: Re: Reasons for single entry, single exit |
|
|
"John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote
[SNIP]
| Quote: | Just for completeness, avoid the extra == using a bool in
case we want this for something more complicated than int.
Bi find_last (Bi a, Bi n, int t) {
Bi x(n);
bool found(false);
while (! (found || x == a))
found = *--x == t;
return found ? x : n;
}
How about SEME?
Bi find_last (Bi a, Bi n, int t) {
for (Bi x(n); x != a; )
if (*--x == t) return x;
return n;
}
This looks like a real win for SEME; however, S&L knew about this
and solved it with reverse_iterator.
[SNIP] |
As you concede, it is hard to see how you could argue that the SESE form
you
give above displays its logic better than your SEME alternative.
Effective
display of logic is, as you said earlier, a principal reason to prefer
one
implementation over another.
The greater legibility of SEME is similarly apparent in implementing a
great
many algorithms. The existence of reverse_iterator as a solution to this
particular problem does indeed sidestep the SEME/SESE issue *for this
particular problem*, but this sidestepping cannot be generalised to all
algorithms in which SEME is more legible. Thus, there will be cases
where
there is "a real win for SEME" but no convenient equivalent to
reverse_iterator exists, and you won't be able to escape the fact.
reverse_iterator was hardly invented just to make a SESE implementation
of
find_last as understandable as the SEME version!
George
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
George van den Driessche
Guest
|
| Posted: Thu Jun 26, 2003 7:17 pm Post subject: Re: Reasons for single entry, single exit |
|
|
"John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote
| Quote: | On 23 Jun 2003 21:56:51 -0400, Doug Harrison <dsh (AT) mvps (DOT) org> wrote:
[SNIP]
We still have the preference of some for the break/return with no
rules to control when it is reasonable. It seems that the
complexity
and readability of the two are equal. What is the justification
for using the non-SESE version other than the joy of having no
rules?
Restricting oneself to SESE can mean introducing artificial booleans
to help control flow. They increase complexity, because they can
complicate loop conditions and require one to ensure that after
setting them, subsequent code that should not be executed is not
executed.
Why is it that neither paper nor any of the posts including yours
demonstrate this?
|
I can't say why examples are absent from the papers, but your own post
from
a different branch, in which you implement find_last in each way,
demonstrates admirably the introduction of a boolean to aid control flow
and
also the resulting complication of a loop condition.
George
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andy Sawyer
Guest
|
| Posted: Thu Jun 26, 2003 7:34 pm Post subject: Re: Reasons for single entry, single exit |
|
|
In article <qckkfv43k3p2olhrbhfhvnccssc0bo9pob (AT) 4ax (DOT) com>,
on 26 Jun 2003 10:15:30 -0400,
John Potter <jpotter (AT) falcon (DOT) lhup.edu> wrote:
| Quote: | String::npos is not a magic number in the middle of the range which
only
applies to signed numbers. It is a sentinel value defined within the
class.
|
And within the standard.
Regards,
Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there
first,
and is waiting for it." -- Terry Pratchett, Reaper Man
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
