C++ Primer exercise 3.13

[arnuld]

i have solved the problem but it is quite length. as usual, i wanted some
coding-standards or good-design opinions:
/* C++ Primer 4/e
* chapter 3 - Library Types

* exercise 3.13
* STAMEMENT
* read a set of integers into the vector. calculate and print the
sum of each * pair of adjacent elements of the vector. If there is an odd
number then tell the * user about it and print the value of the last
element without summing it. *
*/
#include <iostream>
#include <vector>

int main()
{
std::vector<intivec; /* empty vector */

int ivec_limit = 11;
for(int i = 5; i != ivec_limit; ++i) /* inserts itegers */
ivec.push_back(i);

/* now we will print the elements of vector */ std::cout << "These are
the elements of vector:\t"; for(std::vector<int>::const_iterator
iter=ivec.begin(); iter != ivec.end(); ++iter)
{
std::cout << *iter << " ";
}

std::cout << std::endl;
/* actual programme */
for(std::vector<int>::iterator iter = ivec.begin(); iter != ivec.end();
++iter)
{
if((*iter % 2) != 0)
{
std::cout << "\n"
<< *iter
<< " is an odd number"
<< " not adding it to the total."
<< std::endl;
if(iter == ivec.begin())
{
std::cout << *iter
<< " is the 1st element of vector"
<< std::endl;
}
else
{
std::cout << "--last element was: "
<< *(iter - 1)
<< std::endl;
}
}
else
{
if((iter + 1) == ivec.end())
{
std::cout << "\nLast element of vector is: "
<< *iter
<< std::endl;
}
else
{
std::cout << "\nAdjacent elements are: "
<< *iter
<< " & "
<< *(iter + 1)
<< "\n--and their sum is: "
<< *iter + *(iter + 1)
<< std::endl;
}
}
}
return 0;
}
===== OUTPUT =============
[arnuld@arch cpp ]% g++ -ansi -pedantic -Wall -Wextra ex_03-13.cpp
[arnuld@arch cpp ]% ./a.out
These are the elements of vector: 5 6 7 8 9 10

5 is an odd number not adding it to the total. 5 is the 1st element of
vector

Adjacent elements are: 6 & 7
--and their sum is: 13

7 is an odd number not adding it to the total. --last element was: 6

Adjacent elements are: 8 & 9
--and their sum is: 17

9 is an odd number not adding it to the total. --last element was: 8

Last element of vector is: 10
[arnuld@arch cpp ]%

--
-- http://arnuld.blogspot.com

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-07-19 10:35, arnuld wrote:

i have solved the problem but it is quite length. as usual, i wanted some
coding-standards or good-design opinions:
/* C++ Primer 4/e
* chapter 3 - Library Types

* exercise 3.13
* STAMEMENT
* read a set of integers into the vector. calculate and print the
sum of each * pair of adjacent elements of the vector. If there is an odd
number then tell the * user about it and print the value of the last
element without summing it. *
*/

Sorry, but you have not solved the problem the author intended. First of
you should let the user enter the numbers. Then you should print the sum
of each pair of numbers, but if the user entered an odd number of
numbers you can't sum the last element with another so you you should
just print it:

So an example run could look something like this:
--
Please enter some numbers:
1
2
3
4
5

You entered an odd number of numbers.

The sums of the pairs are:
3
7
5
--
Or like this:
--
Please enter some numbers:
1
2
3
4
5
6

The sums of the pairs are:
3
7
11

--
Erik Wikström

[arnuld]

On Thu, 19 Jul 2007 09:23:21 +0000, Erik Wikström wrote:

Sorry, but you have not solved the problem the author intended. First of
you should let the user enter the numbers. Then you should print the sum
of each pair of numbers, but if the user entered an odd number of
numbers you can't sum the last element with another so you you should
just print it:

ok, BTW, i found the statement ambiguous. so i created the programem on
that basis of what it could mean.

So an example run could look something like this: -- Please enter some
numbers:
1
2
3
4
5

You entered an odd number of numbers.

The sums of the pairs are:
3
7
5

sorry, after 1.5 hours of grueling work, my new programme still gives
"segmentatioon fault" on finding an odd list of numbers. for even amount
of numbers this programme works:

#include <iostream>
#include <vector>

int main()
{
std::vector<intivec; /* empty vector */ int v_num;

std::cout << "Please enter some numbers: " << std::endl; while(std::cin

>v_num)

ivec.push_back(v_num);

if((ivec.size() % 2) != 0)
{
std::cout << "oops!, you enetered an odd number of numbers" <<
std::endl;
}

std::cout << "The sum of the pairs are: " << std::endl; /* actual
programme */
for(std::vector<int>::const_iterator iter = ivec.begin(); iter !=
ivec.end(); iter += 2)
{
if((iter + 1) == ivec.end())
{
std::cout << *iter << std::endl;
}
else
{
std::cout << *iter + *(iter + 1) << std::endl;
}
}

return 0;
}
--
-- http://arnuld.blogspot.com

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-07-19 13:41, arnuld wrote:

>On Thu, 19 Jul 2007 09:23:21 +0000, Erik Wikström wrote:

>Sorry, but you have not solved the problem the author intended. First of
you should let the user enter the numbers. Then you should print the sum
of each pair of numbers, but if the user entered an odd number of
numbers you can't sum the last element with another so you you should
just print it:

ok, BTW, i found the statement ambiguous. so i created the programem on
that basis of what it could mean.

>So an example run could look something like this: -- Please enter some
numbers:
1
2
3
4
5

You entered an odd number of numbers.

The sums of the pairs are:
3
7
5

sorry, after 1.5 hours of grueling work, my new programme still gives
"segmentatioon fault" on finding an odd list of numbers. for even amount
of numbers this programme works:

#include <iostream>
#include <vector>

int main()
{
std::vector<intivec; /* empty vector */ int v_num;

std::cout << "Please enter some numbers: " << std::endl; while(std::cin

>v_num)

ivec.push_back(v_num);

if((ivec.size() % 2) != 0)
{
std::cout << "oops!, you enetered an odd number of numbers" <<
std::endl;
}

std::cout << "The sum of the pairs are: " << std::endl; /* actual
programme */
for(std::vector<int>::const_iterator iter = ivec.begin(); iter !=
ivec.end(); iter += 2)

Replace the check to a less than (iter < ivec.end()), since you are
increasing the iterator with 2 each step you will step over ivec.end()
if the number of elements is odd..

{
if((iter + 1) == ivec.end())
{
std::cout << *iter << std::endl;

Or add break; here.

}
else
{
std::cout << *iter + *(iter + 1) << std::endl;
}
}

return 0;
}

--
Erik Wikström

[arnuld]

On Thu, 19 Jul 2007 12:01:55 +0000, Erik Wikström wrote:

>On 2007-07-19 13:41, arnuld wrote:
for(std::vector<int>::const_iterator iter = ivec.begin(); iter !=
ivec.end(); iter += 2)

Replace the check to a less than (iter < ivec.end()), since you are
increasing the iterator with 2 each step you will step over ivec.end()
if the number of elements is odd..

that i never thought of

> {
if((iter + 1) == ivec.end())
{
std::cout << *iter << std::endl;

Or add break; here.

this is what i wanted. i supposed and befooled myself into thinking that
since now test is true only this one statement will execute but i forgot
about the for loop :(

--
-- http://arnuld.blogspot.com

[Andre Kostur]

=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?= <Er***********@telia.comwrote in
news:To****************@newsb.telia.net:

On 2007-07-19 13:41, arnuld wrote:

>>On Thu, 19 Jul 2007 09:23:21 +0000, Erik Wikström wrote:

>>Sorry, but you have not solved the problem the author intended.
First of you should let the user enter the numbers. Then you should
print the sum of each pair of numbers, but if the user entered an
odd number of numbers you can't sum the last element with another so
you you should just print it:

ok, BTW, i found the statement ambiguous. so i created the programem
on that basis of what it could mean.

>>So an example run could look something like this: -- Please enter
some numbers:
1
2
3
4
5

You entered an odd number of numbers.

The sums of the pairs are:
3
7
5

sorry, after 1.5 hours of grueling work, my new programme still gives
"segmentatioon fault" on finding an odd list of numbers. for even
amount of numbers this programme works:

#include <iostream>
#include <vector>

int main()
{
std::vector<intivec; /* empty vector */ int v_num;

std::cout << "Please enter some numbers: " << std::endl;
while(std::cin

> >v_num)

ivec.push_back(v_num);

if((ivec.size() % 2) != 0)
{
std::cout << "oops!, you enetered an odd number of numbers" <<
std::endl;
}

std::cout << "The sum of the pairs are: " << std::endl; /* actual
programme */
for(std::vector<int>::const_iterator iter = ivec.begin(); iter !=
ivec.end(); iter += 2)

Replace the check to a less than (iter < ivec.end()), since you are
increasing the iterator with 2 each step you will step over ivec.end()
if the number of elements is odd..

Caveat: this is not good general advice. Testing for != end() is better
than testing for < end() as it is how one does the same sort of test for
the other containers. May work for vectors, won't work for the other
containers.

Finally, assuming that the += 2 steps past the end() iterator, isn't it
technically undefined behaviour to make the comparison as you would be
comparing a pointer to an element within an array (one-past-the-end
pointer is still considered to be "within the array") to a pointer that
isn't in the same array (and isn't 0)?

> {
if((iter + 1) == ivec.end())
{
std::cout << *iter << std::endl;

Or add break; here.

I think this may be a better choice. Then again, I'd probably using
indexing for this instead of iteration (which does pretty much tie me to
vector...). Or perhaps use a while loop instead of a for.

> }
else
{
std::cout << *iter + *(iter + 1) << std::endl;
}
}

return 0;
}

[James Kanze]

On Jul 19, 2:01 pm, Erik Wikström <[e-mail]:

On 2007-07-19 13:41, arnuld wrote:

[...]

#include <iostream>
#include <vector>

int main()
{
std::vector<intivec; /* empty vector */ int v_num;

std::cout << "Please enter some numbers: " << std::endl; while(std::cin

>v_num)

ivec.push_back(v_num);

if((ivec.size() % 2) != 0)
{
std::cout << "oops!, you enetered an odd number of numbers" <<
std::endl;
}

std::cout << "The sum of the pairs are: " << std::endl; /* actual
programme */
for(std::vector<int>::const_iterator iter = ivec.begin(); iter !=
ivec.end(); iter += 2)

Replace the check to a less than (iter < ivec.end()), since you are
increasing the iterator with 2 each step you will step over ivec.end()
if the number of elements is odd..

That won't work either, since you'll still enter the loop when
there is only one element remaining (and thus add 2, resulting
in undefined behavior). Interpreting the requirements strictly,
I'd use something like:

while ( iter != end && iter + 1 != end ) {
// ...
iter +=2 ;
}
if ( iter != end ) {
// odd number...
}

Interpreting them a bit more loosely, I'd probably use a vector
of std::pair< int, int >, and handle the case of an odd number
of elements at input. (In a real world application, I'd
probably require two integers per line, and use getline to
read.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 19, 4:14 pm, Andre Kostur <[e-mail]:

=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?= <[e-mail] innews:To****************@newsb.telia.net:

On 2007-07-19 13:41, arnuld wrote:

>On Thu, 19 Jul 2007 09:23:21 +0000, Erik Wikström wrote:

Replace the check to a less than (iter < ivec.end()), since
you are increasing the iterator with 2 each step you will
step over ivec.end() if the number of elements is odd..

Caveat: this is not good general advice. Testing for != end()
is better than testing for < end() as it is how one does the
same sort of test for the other containers. May work for
vectors, won't work for the other containers.

Agreed, sort of. It's what one expects, and code should provide
the least surprises to the reader. But he needs random access
iterators for the + 1 as well, so the code won't work for other
containers anyway.

Finally, assuming that the += 2 steps past the end() iterator,
isn't it technically undefined behaviour to make the
comparison as you would be comparing a pointer to an element
within an array (one-past-the-end pointer is still considered
to be "within the array") to a pointer that isn't in the same
array (and isn't 0)?

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.)

{
if((iter + 1) == ivec.end())
{
std::cout << *iter << std::endl;

Or add break; here.

I think this may be a better choice.

Using a break to leave a loop is NEVER a good choice.

Then again, I'd probably using indexing for this instead of
iteration (which does pretty much tie me to vector...). Or
perhaps use a while loop instead of a for.

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 Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[arnuld]

On Fri, 20 Jul 2007 08:22:32 +0000, James Kanze wrote:

Agreed, sort of. It's what one expects, and code should provide the
least surprises to the reader. But he needs random access iterators for
the + 1 as well, so the code won't work for other containers anyway.

:-(

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 :)

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".

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.
--
-- http://arnuld.blogspot.com

[Andre Kostur]

arnuld <ge*********@gmail.comwrote in news:pan.2007.07.20.09.46.53.778891
@gmail.com:

>On Fri, 20 Jul 2007 08:22:32 +0000, James Kanze wrote:

[snip]

>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".

For that, and switch statements. However it is a tool that is easily
misused. By using break you are stepping outside of the expected code
flow. Much like scattering goto's all over your code too. I'm not sure
that "never" is a good word, but it should probably be avoided where
possible.

[snip while solution]

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.

There are three looping constructs in C++ language itself... "for",
"while", and "do..while". Learn them all as each one has certain
behaviours and makes them better for various situations. Keep in mind that
each one could be implemented in terms of one of the other ones, but the
syntax would get awkward and you'd only be obscuring your intent. In
addition there are other constructs in the Standard Library that do loop-
like things, such as std::for_each, std::transform, and others.

[James Kanze]

On Jul 20, 11:46 am, arnuld <[e-mail]:

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: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 20, 10:59 pm, "Bo Persson" <[e-mail]:

Zachary Turner wrote:

:: On Jul 20, 9:21 am, Andre Kostur <[e-mail]:
::: arnuld <[e-mail] in
::: news:pan.2007.07.20.09.46.53.778891 @gmail.com:

::::: On Fri, 20 Jul 2007 08:22:32 +0000, James Kanze wrote:
::::: 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".

::: For that, and switch statements. However it is a tool that is
::: easily misused. By using break you are stepping outside of the
::: expected code flow. Much like scattering goto's all over your
::: code too. I'm not sure that "never" is a good word, but it
::: should probably be avoided where possible.

:: break and continue statements are like my bread and butter. I've
:: personally never read any literature suggesting that break and goto
:: are even in the same category in terms of their tendency to produce
:: spaghetti code.

Using goto is definitely worse.

It depends. Using goto any old way is definitely worse, but
what about a goto to break out of nested loops. (I've heard
that one defended many times. After all, if you accept breaking
out of a single loop, why not breaking out of nested loops?)

Some people prefer "clever" code to correct code.

I think James' problem with breaking
out of a for or while loop is that the break in the middle makes the
initial statement false.

Partially. The real problem is that you've increased the
cyclometric complexity, and hidden the fact.

There are, in a certain sense, two somewhat distinct problems
involved. The first is that a loop should have a single entry
and a single exit point. Anything else increases the
cyclometric complexity, and makes the code considerably more
difficult to understand and to maintain. From this point of
view, however, something along the lines of:

for ( ;; ) {
// some code...
if ( someCondition )
break ;
// more code...
}

does not cause a problem; it's just a straightforward
implementation of the loop and a half problem. The second
aspect is simply readability in the language you are using. C++
has constructs (while, for) for checking the condition at the
top of the loop, and one (do...while) for checking it at the
bottom, but nothing readable for checking it in the middle. In
specific shops, it's possible to define a convention which would
make things readable---to begin with, the if above is clearly
part of the loop control, and so should be indented to align
with the for, and not with the controled code. (Try to get your
automatic indention to respect that:-).) But anything you agree
on there is specific to the shop, and can't be portably counted
on.

You don't loop as long as you initially said,
but sometimes change your mind halfway through. Not good!

Worse: you said you'be loop as long as e.g. "x < 5", but you
don't. You said that a guaranteed post-condition of the loop
was "x >= 5", but it isn't.

That's really the fundamental problem with the loop and a half
idiom I suggested above: you promess that the loop will never
terminate (barring catastropic failure), but it does.

I might use a break sometimes, when the terminating condition isn't
available at either end of the loop, like in:

while(true)
{
// some inital sequence
if (particular_condition)
break;
// some more code (that might remove the condition)
}

Here the while(true) is such an obvious lie, that the reader
should expect another condition later.

Context dependent:-). The code I write often does contain
endless loops. (The software runs 24 hours a day, 7 days a
week.)

:: To me, the number one factor affecting
:: readability of code is the number of levels of indentation.

True.

Not exactly as stated. If it were literally true, just don't
indent. I'm sure that that's not what the poster meant, but
what did he mean, in fact. Increasing cyclometric complexity
never improves readability, and break and continue do introduce
additional control flows, and so increase cyclometric
complexity.

[Concerning multiple returns...]

I think this is acceptable, especially if there are several special
param values that can be easily taken care of early.

The problem is estabilishing the rules when it would be
acceptable. I DO have code with multiple returns: if the entire
function body is a switch, for example, I'll occasionally use a
return at the end of each case (rather than break). But it's
difficult (for me at least) to formulate any reasonable rule;
something along the lines: only in a top level control
structure, and then only if all alternative paths terminate with
a return? For the moment, I just consider the switch case a
special case, and let it go at that. (Switches are special
cases with regards to cyclometric complexity anyway.)

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]