Accelerated C++: [1,rows] Not so fast

[Steven T. Hatton]

I've finally gotten around to reading Accelerated C++ by Andrew Koenig and
Barbara Moo. There's a lot of good stuff in what I've read so far. Even
though it is _very_ basic, they present some concepts I have not
encountered elsewhere, or explain ones I have encountered in ways that add
to my understanding. There are a few points of style with which I take
issue, such as not consistently using braces around the body of an if or
loop, etc.

There is one point, however, I have to take exception too. They assert that
"...the number of elements in [0, rows) is obvious(i.e., rows -0, or rows)
but the number of elements in [1,rows[ is less so." If you agree with
these authors, please turn off the computer and reflect for a moment on
your preschool and kindergarden years. Hold up your hand and look at your
fingers. Remember? "One", "two", "three"....? ;-)
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Andrew Koenig]

There is one point, however, I have to take exception too. They assert
that
"...the number of elements in [0, rows) is obvious(i.e., rows -0, or rows)
but the number of elements in [1,rows[ is less so." If you agree with
these authors, please turn off the computer and reflect for a moment on
your preschool and kindergarden years. Hold up your hand and look at your
fingers. Remember? "One", "two", "three"....? ;-)

Indeed -- People form bad habits early.

If you are in the habit of representing ranges by storing the first and last
element of the range, our experience from years of teaching is that you are
much more likely to run into trouble than you are if you form the habit of
representing ranges by storing the first and one past the last element.

Moreover, once you graduate from ranges of integers to ranges of iterators,
you no longer have a choice in the matter, because there is no way to
represent an empty range if you insist on referring to the last element
rather than one past the last.

 

[Steven T. Hatton]

Andrew Koenig wrote:

Indeed -- People form bad habits early.

If you are in the habit of representing ranges by storing the first and
last element of the range, our experience from years of teaching is that
you are much more likely to run into trouble than you are if you form the
habit of representing ranges by storing the first and one past the last
element.

Moreover, once you graduate from ranges of integers to ranges of
iterators, you no longer have a choice in the matter, because there is no
way to represent an empty range if you insist on referring to the last
element rather than one past the last.

I don't disagree with what you're saying. I've never thought about the issue
from that perspective. I simply accepted that C and hence C++ works that
way because it's more consistent with the hardware representation. I know
I can get pretty disoriented if I start working with Mathematica after a
long period of exclusively working with C++. Mathematica starts indexing
at 1, sort of. The zeroth element of a List is 'List'.

I was really commenting on the impact that counting from 0 has on our
thinking. I worked with vectors an matrices for years in mathematics
before I started working with computers. Now the idea of indexing from 1
seems a bit foreign. I sometimes wonder if mathematics will every recover
from computer science.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[David White]

I've finally gotten around to reading Accelerated C++ by Andrew Koenig and
Barbara Moo. There's a lot of good stuff in what I've read so far. Even
though it is _very_ basic, they present some concepts I have not
encountered elsewhere, or explain ones I have encountered in ways that add
to my understanding.

One comment that I've come across many times is that it's hard going for
beginners, i.e., not basic enough, though I don't know what level it's
aimed at. I have not actually read it. The bookshops here don't have it.
They prefer to stock "Learn C++ in 30 seconds", or whatever it's called.

DW

 

[ES Kim]

I've never thought about the issue
from that perspective. I simply accepted that C and hence C++ works that
way because it's more consistent with the hardware representation.

Neither have I. And I was quite impressed by the representation of an empty
range by [n, n). The book shows some fundametal but easy-to-ignore points.

 

[Andrew Koenig]

One comment that I've come across many times is that it's hard going for
beginners, i.e., not basic enough, though I don't know what level it's
aimed at. I have not actually read it. The bookshops here don't have it.
They prefer to stock "Learn C++ in 30 seconds", or whatever it's called.

Accelerated C++ covers more material in its 320 pages than many 1000-page
introductory books. It does so by not dwelling on unimportant details and
avoiding needless repetition. As a result, you have to read it thoroughly:
You can't just open it at random and expect that you'll be able to
understand whatever you see without first having read what precedes it.

On the other hand, if you do take the time to read it thoroughly, I believe
you will learn more in less time than if you were to use a more conventional
book. The reason is that one of its organizing principles is "Teach the
most useful ideas first." That is, at each point in the book, we present
the idea that we think will add the most to your programming skills beyond
what you have already learned up to that point.

Who is the intended audience? Someone who already has some programming
experience (not necessarily a lot), and who can figure out the mechanics of
writing and running C++ programs. I know that several people are using it
as textbooks in introductory college computer-science courses. It would
also be well suited for software developers who have never used C++ but who
have programmed in other languages.

I think it might even be useful for a complete novice, provided that there
was someone around to help as needed. I think it's a little steep for
self-study by a nonprogrammer.

 

[Howard]

I've never thought about the issue
from that perspective. I simply accepted that C and hence C++ works that
way because it's more consistent with the hardware representation.

Neither have I. And I was quite impressed by the representation of an
empty
range by [n, n). The book shows some fundametal but easy-to-ignore points.

I find that notation to be rather silly. Something more like [] would be
better, in my opinion, except that of course we're dealing with takng that
representation and applying it to something real (assuming you can call C++
"real" ).
What does [n,n) mean, if translated into everyday language? It's the range
of integers starting at and including n, up to but NOT including n. Umm...
what??? The first part says to include n, and the second says to not
include n. Very weird.
It's obvious, as a programer, how that representation can be implemented in,
for example, a for loop. But it's no different, really, from saying
something like [100,-5]. That's just as "emtpy" as [n,n), isn't it?

Just my $0.02 (and as valueless as that is).

-Howard

 

[Steven T. Hatton]

I've never thought about the issue
from that perspective. I simply accepted that C and hence C++ works
that way because it's more consistent with the hardware representation.

Neither have I. And I was quite impressed by the representation of an
empty
range by [n, n). The book shows some fundametal but easy-to-ignore
points.

I find that notation to be rather silly. Something more like [] would be
better, in my opinion, except that of course we're dealing with takng that
representation and applying it to something real (assuming you can call
C++ "real" ).
What does [n,n) mean, if translated into everyday language? It's the
range
of integers starting at and including n, up to but NOT including n.
Umm...
what??? The first part says to include n, and the second says to not
include n. Very weird.
It's obvious, as a programer, how that representation can be implemented
in,
for example, a for loop. But it's no different, really, from saying
something like [100,-5]. That's just as "emtpy" as [n,n), isn't it?

Just my $0.02 (and as valueless as that is).

-Howard

It's really standard mathematical notation for a set. There's nothing novel
to me in the notation itself. What I found a bit amusing was the idea that
it is easier to determine the number of elements in the set {0,1,2,...,n-1}
than in the set {1,2,3,...,n}.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Steven T. Hatton]

I think it might even be useful for a complete novice, provided that there
was someone around to help as needed. I think it's a little steep for
self-study by a nonprogrammer.

I'm finding that it is fairly 'self-contained'. That is, it makes very few
assumptions about prior programming knowledge, and presents every necessary
concept as appropriate. Though it presents the material at a basic level,
it doesn't condescend to the reader. It also presents - as I previously
indicated - some ideas I haven't encountered elsewhere. I'm certainly
getting more from the book than simply a review of the material covered in
TC++PL(SE).

I suspect the hardest part of working through the book for a person with
little programming experience would be the challenge of figuring out the
mechanics of working with the particular implementation. IDE's can add a
lot of distracting content to even the simplest of programs, and the
g++(for example) command line interface is not what I would call intuitive.

Of course they could use Emacs... vi? My own opinion is that a person
would be well served by fetching Cygwin - or installing an operating system
- and learning to work with their compiler from the command line. I'd
suggest TextPad (ShareWare) as an editor if they are restricted to a
Windows environment.

One advantage I got from using KDevelop when I started programming in C++ is
that it created my header/source file pairs in a useful way.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Andrew Koenig]

I find that notation to be rather silly. Something more like [] would be
better, in my opinion, except that of course we're dealing with takng that
representation and applying it to something real (assuming you can call
C++ "real" ).
What does [n,n) mean, if translated into everyday language? It's the
range of integers starting at and including n, up to but NOT including n.
Umm... what??? The first part says to include n, and the second says to
not include n. Very weird.

The notation has many years of usage in mathematics. I didn't invent it.

It's obvious, as a programer, how that representation can be implemented
in, for example, a for loop. But it's no different, really, from saying
something like [100,-5]. That's just as "emtpy" as [n,n), isn't it?

Yes it is. However, the number of elements in [m,n) is n-m; the number of
elements in [m,n] is n+1-m (assuming zero in both cases if the count is
negative). The "+1" is the source of untold off-by-one errors in programs.

 

[Howard]

I've never thought about the
issue
from that perspective. I simply accepted that C and hence C++ works
that way because it's more consistent with the hardware representation.

Neither have I. And I was quite impressed by the representation of an
empty
range by [n, n). The book shows some fundametal but easy-to-ignore
points.

I find that notation to be rather silly. Something more like [] would be
better, in my opinion, except that of course we're dealing with takng
that
representation and applying it to something real (assuming you can call
C++ "real" ).
What does [n,n) mean, if translated into everyday language? It's the
range
of integers starting at and including n, up to but NOT including n.
Umm...
what??? The first part says to include n, and the second says to not
include n. Very weird.
It's obvious, as a programer, how that representation can be implemented
in,
for example, a for loop. But it's no different, really, from saying
something like [100,-5]. That's just as "emtpy" as [n,n), isn't it?

Just my $0.02 (and as valueless as that is).

-Howard

It's really standard mathematical notation for a set. There's nothing
novel
to me in the notation itself. What I found a bit amusing was the idea
that
it is easier to determine the number of elements in the set
{0,1,2,...,n-1}
than in the set {1,2,3,...,n}.
--

Actually, as you've just shown, sets us curly bracket notation. And, the
notation for an empty set is {}, not [n,n).

All I'm saying is that it's incredibly odd to use this specific instance of
the notation: [n,n), because the left square bracket here explicitly means
to include the number following it (n), and the right paren just as
explicitly states to NOT include the number to its left (n). So... the
notation contradicts itself. Undoubtedly, it's convenient to say [n,n) in
order to construct a programming model from the mathematical model, and
maybe it's even commonly used (although I sure don't recall seeing it in my
degree studies), but there's no way to deny that this *particular* use of
the notation is self-contradictory.

-Howard

 

[Steven T. Hatton]

Actually, as you've just shown, sets us curly bracket notation. And, the
notation for an empty set is {}, not [n,n).

There are multiple forms of notation for sets. To say sets use curly
brackets does not exclude the use of the use of square brackets and
parentheses. The latter is commonly used in analysis (the Calculus).

All I'm saying is that it's incredibly odd to use this specific instance
of the notation: [n,n), because the left square bracket here explicitly
means to include the number following it (n), and the right paren just as
explicitly states to NOT include the number to its left (n). So... the
notation contradicts itself.

Ok, now I understand what you were getting at. I agree that it seems a bit
odd. OTOH, it does follow naturally from the notation, and seems to
communicate something of meaning. I'd argue that it actually says more
than simply [n,n) = {}; It says we are talking about an empty range
located (beginning) at n. It's kind of like the empty string used in
regular expressions such as the empty string at the beginning of a word.

Undoubtedly, it's convenient to say [n,n) in
order to construct a programming model from the mathematical model, and
maybe it's even commonly used (although I sure don't recall seeing it in
my degree studies), but there's no way to deny that this *particular* use
of the notation is self-contradictory.

-Howard

Well..., it really depends on the subtelties of your definitions. There is
always the escape of defining the special case to mean such and such, e.g.,
x^0===1. I would argue that [n,n) is a degenerate case which
reasonably /suggests/ [n,n)==={}. But we're heading off topic.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Steven T. Hatton]

Howard wrote:

[...]

See what you can make of this:

http://mathworld.wolfram.com/Interval.html

I haven't formed a conclusive opinion as to whether they address the case of
[n,n).
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[E. Mark Ping]

Howard wrote:

[...]

See what you can make of this:

http://mathworld.wolfram.com/Interval.html

I haven't formed a conclusive opinion as to whether they address the case of
[n,n).

It's called a "half-open" or "half-closed" interval. A half-open
interval has very good properties, especially on the integers.
Especially that the union of the two intervals:

[a,b) U [b,c)

is also a half-open interval: [a,c)

See: http://mathworld.wolfram.com/Half-ClosedInterval.html

 

[Steven T. Hatton]

Howard wrote:

[...]

See what you can make of this:

http://mathworld.wolfram.com/Interval.html

I haven't formed a conclusive opinion as to whether they address the case
of
[n,n).

It's called a "half-open" or "half-closed" interval. A half-open
interval has very good properties, especially on the integers.
Especially that the union of the two intervals:

[a,b) U [b,c)

is also a half-open interval: [a,c)

See: http://mathworld.wolfram.com/Half-ClosedInterval.html

We are specifically interested in the case of [a,a) i.e., [a,b) where b = a.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Andrew Koenig]

All I'm saying is that it's incredibly odd to use this specific instance
of the notation: [n,n), because the left square bracket here explicitly
means to include the number following it (n), and the right paren just as
explicitly states to NOT include the number to its left (n). So... the
notation contradicts itself. Undoubtedly, it's convenient to say [n,n) in
order to construct a programming model from the mathematical model, and
maybe it's even commonly used (although I sure don't recall seeing it in
my degree studies), but there's no way to deny that this *particular* use
of the notation is self-contradictory.

Either that or your notion of what the notation represents should be
adjusted.

Here's another way to look at it: For all integers m, n, the notation "[m,
n)" is the ascending sequence of integer values k, with the property that m
<= k and k < n. Now the contradiction vanishes.

 

[Andrew Koenig]

See what you can make of this:

http://mathworld.wolfram.com/Interval.html

It talks about real numbers, not integers, but is relvant aside from that.
Note that there are lots of issues, such as compactness, that apply to reals
but not to integers.

I haven't formed a conclusive opinion as to whether they address the case
of
[n,n).

They do, by saying that treating the empty set as an integral makes a bunch
of other properties equivalent. By implication, they could choose to define
the notion of interval to exclude the empty set, but they feel it is more
useful to do otherwise.

 

[E. Mark Ping]

Especially that the union of the two intervals:

[a,b) U [b,c)

is also a half-open interval: [a,c)

See: http://mathworld.wolfram.com/Half-ClosedInterval.html

We are specifically interested in the case of [a,a) i.e., [a,b) where
b = a.

My apologies for being too terse. I've never seen standard
nomenclature for [a,a), but it makes sense in this case to define it
as the empty set, since that means the union property holds:

[a,a) U [a,b) = [a,b)

Similarly, 0! is commenly defined as 1 becuase it's most useful with
that definition in combinatorics, but AFAIK it's not a universally
accepted definition.

 

[Steven T. Hatton]

My apologies for being too terse. I've never seen standard
nomenclature for [a,a), but it makes sense in this case to define it
as the empty set, since that means the union property holds:

[a,a) U [a,b) = [a,b)

Similarly, 0! is commenly defined as 1 becuase it's most useful with
that definition in combinatorics, but AFAIK it's not a universally
accepted definition.

I have a serious reservation about accepting the idea of [a,a) = {}. After
thinking it over, it seems to me that [a,a) carries more information than
{}. In order for [a,a) = {} to be true, [a,a) = [b,b) where a != b; I'm
not sure I'm willing to accept that proposition. In particular, I'm not
sure I'm willing to extend it to the concept of indexing of memory
locations.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[E. Mark Ping]

My apologies for being too terse. I've never seen standard
nomenclature for [a,a), but it makes sense in this case to define it
as the empty set, since that means the union property holds:

[a,a) U [a,b) = [a,b)

Similarly, 0! is commenly defined as 1 becuase it's most useful with
that definition in combinatorics, but AFAIK it's not a universally
accepted definition.

I have a serious reservation about accepting the idea of [a,a) = {}. After
thinking it over, it seems to me that [a,a) carries more information than
{}.

Well of course it does. 0! carries more information that 1.

In order for [a,a) = {} to be true, [a,a) = [b,b) where a != b; I'm
not sure I'm willing to accept that proposition.

I don't know why not. Note the equivalence:

[a,a) U [a,b) = [a,b)
[b,b) U [a,b) = [a,b)

Definining [a,a) = {} is just as useful as defining 0! = 1.

In particular, I'm not sure I'm willing to extend it to the concept
of indexing of memory locations.

Why not?

while (p!=q)
{
*p++ = *q++;
}

Is meaningful for p and q even if p==q at the beginning of the loop.