Re: C++ Primer exercise 3.13
On Jul 20, 11:46 am, arnuld <geek.arn...@gmail.com> wrote:
On Fri, 20 Jul 2007 08:22:32 +0000, James Kanze wrote:
It's not only undefined behavior; it crashes with both g++
and VC++ when you turn on debugging options. (You should be
using the debugging options whenever possible, especially
when learning. Regretfully, code compiled with the
debugging options is not compatible with code compiled
without. The debugging options have significant runtime
overhead, and a bottleneck anywhere in the application means
that you can't use them anywhere.)
ok, i have added "-ggdb" to my arsenal :)
That's not really the "debug" option in the sense I was thinking
of. That one puts the symbol table information in the object
file, so that it is available to the debugger. What I was
thinking of was the options which cause the compiler to generate
additional debugging checks in the library:
-D_GLIBCXX_CONCEPT_CHECKS -D_GLIBCXX_DEBUG -
D_GLIBCXX_DEBUG_PEDANTIC
(In practice, you should always use -ggdb too. I almost never
use a debugger, but you can be sure that the one time I forget
the -ggdb will be the one time I will want to use it.)
Using a break to leave a loop is NEVER a good choice.
and i am the one who always believed that "break" was
especially created for the purpose of "breaking out of loop".
"break" was created in C. So was "goto". That doesn't make
them "good practice". In general, you should enter a loop at
the top, and leave it at the bottom. In good code, about the
only place you'll see a break is to terminate a case in a
switch. (And I know, that's an over-generalization. There are
cases where using a break is probably preferable to the
alternatives, although I can't recall seeing any for the longest
time. An experienced, professional programmer will recognize
them, and be able to justify them. But since you're still
learning, it's better to stick with the simple, absolute rule
for the moment.)
There's a very nice solution with a while loop:
while ( iter != ivec.end() ) {
{
int first = *iter ++ ;
if ( iter != ivec.end() ) {
int second = *iter ++ ;
std::cout << first + second << std::endl ;
} else {
std::cout << "odd number of elements, last was: "
<< first << std::endl ;
}
}
}
I'm not overly enthusiastic about spreading the increments out all over
the loop, but it seems preferable here to the alternatives. It also
avoids the requirement for a random access iterator, so you can replace
vector with just about any container. (I still rather prefer the idea
of using a container of std::pair, however, and handling the odd case at
the end of input.)
James, that is really nice solution, i just loved it :). i always thought
that "for" loop is the official loop of C++ (like 'C' is the official
language of GNU, at least to speak) but i see, in this situation "while"
fits much better.
The "for" loop has the advantage of bringing all of the loop
control up to the top, where it is readily visible. In this
case, of course, it doesn't work because increments are spread
out all over the place. Which isn't ideal, but off hand, I
can't find anything better. The most general form of a loop is
while. If the resulting while is easily translated into a for,
then you can consider it---I tend to use for in every case where
the generic while has the proper form, but opinions about the
exact cases differ slightly in practice. The important thing is
to use for in the obvious cases, corresponding to those where it
would be the proper idiom in another language, and to not use it
when it would require forcing or restructuring the loop. For
the in between cases (and they are legion), find a rule that
you're comfortable with, and be consistent. And be ready to
modify that rule if the company you work for has a different
rule:-).
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34