A new kind of book to learn C++ computer programming

[Kari Laitinen]

I have written a computer programming book that uses C++.
The book is for beginners in the field of computer programming,
but it might give useful ideas also for more experienced
programmers. Computer programs are presented in a very
easy-to-read way in my book. To find out what that exactly
means, please read the pages at

http://www.naturalprogramming.com/cppbook.html

There you can find free sample pages for printing and other
useful information.

I hope that it is ethically correct to advertize the
book in this newsgroup.

Sincerely,
Mr. (Dr.) Kari Laitinen
Oulu Institute of Technology, Finland

 

[Alf P. Steinbach]

I have written a computer programming book that uses C++.
The book is for beginners in the field of computer programming,
but it might give useful ideas also for more experienced
programmers. Computer programs are presented in a very
easy-to-read way in my book. To find out what that exactly
means, please read the pages at

http://www.naturalprogramming.com/cppbook.html

There you can find free sample pages for printing and other
useful information.

I hope that it is ethically correct to advertize the
book in this newsgroup.

Oh yes it is (although spam in general is frowned on).

I looked briefly at chapter 5.

You might want to use standard C++, e.g. <iostream>, instead of
pre-standard C++, <iostream.h>. It took you some years to write that
book, yes? Otherwise looks good.

 

[Kari Laitinen]

I have spent about 7 years in writing the book.
I decided to use <iostream.h> instead of <iostream> because
that way I did not have to say using namespace std ;
at the beginning of every program. By dropping this statement
I wanted to make the first programs a little bit less
confusing for a beginner.

 

[Sam Holden]

I have written a computer programming book that uses C++.

The first complete program I saw was:

---
#include <iostream.h>

int main()
{
cout << "I am a simple computer program." ;
}
---

Why not "<iostream>" and std::cout? What's the point of what I assume
is a new book, not using the modern usage of the language?

No terminating newline is going to make for confused users on many
platforms.

Later on in the "weddingdates" program I see:

#include <iostream.h>
#include <sstream>
#include <string>

Which is a strange mix of the old and the new.

Plus that program then uses 'string' not 'std::string' and hence
won't compile...

 

[Kari Laitinen]

All the programs can be compiled with the free Borland C++ 5.5
compiler. It is true that a few programs in the last chapters
require a statement like using namespace std ; in order to
compile them with Microsoft C++ or with Unix/Linux compilers.

 

[Alf P. Steinbach]

[Do not top-post (see the FAQ) -- rearranged]

I have spent about 7 years in writing the book.
I decided to use <iostream.h> instead of <iostream> because
that way I did not have to say using namespace std ;
at the beginning of every program. By dropping this statement
I wanted to make the first programs a little bit less
confusing for a beginner.

Seven years ago, in 1996, that made very much sense. Even a year or
two after the standard (which appeared late 1997) authors had to make
the hard choice between practically non-compilable standard-conforming
code, compilable non-standard code, or ugly hybrid solutions with "remove
this if your compiler doesn't support namespaces" and the like. Today,
however, most compilers conform to the then not yet existing standard wrt.
this area, which means that some/many of the programs may not even compile,
which is certainly _very_ confusing to the beginner... ;-)

See [http://www.utvikling.com/cppfaq/01/03/index.html] for directions on
obtaining standard-conforming free C++ compilers (this is in Norwegian).

Perhaps it's possible to automate the conversion of most programs?

 

[jeffc]

I have spent about 7 years in writing the book.
I decided to use <iostream.h> instead of <iostream> because
that way I did not have to say using namespace std ;
at the beginning of every program. By dropping this statement
I wanted to make the first programs a little bit less
confusing for a beginner.

Then you should at least say "This is not considered the proper way, but
it's the least complicated in terms of readability for right now." It makes
it worse later on when you mix <...h> and <...> together.

 

[Oliver S.]

... which means that some/many of the programs may not even compile,

which is certainly _very_ confusing to the beginner... ;-)

I hardly doubt that the old header-style isn't supported with any
current compiler as it's too easy to maintain the second style and
thereby to enable old apps to compile without changes.

 

[Alf P. Steinbach]

I hardly doubt that the old header-style isn't supported with any
current compiler as it's too easy to maintain the second style and
thereby to enable old apps to compile without changes.

Difficult to grasp whether you mean you doubt (which would be unfounded
and stupid, since this thread contains one example of a program from that
book that doesn't compile), or whether you mean you don't doubt.

But with such unclear language, perhaps the thoughts that produced the
above are also somewhat muddled?

It wouldn't hardly surprise me.

 

[Artie Gold]

All the programs can be compiled with the free Borland C++ 5.5
compiler. It is true that a few programs in the last chapters
require a statement like using namespace std ; in order to
compile them with Microsoft C++ or with Unix/Linux compilers.

ITYM "in order to conform to standard C++".

Platform/vendor/compiler is irrelevant.
Standards compliance is *always* relevant, particularly in teaching
materials.

Otherwise, it's not C++ you're teaching but, rather, a language that
looks a lot like C++, but isn't.

Cheers,
--ag

 

[Alf P. Steinbach]

ITYM "in order to conform to standard C++".

Platform/vendor/compiler is irrelevant.
Standards compliance is *always* relevant, particularly in teaching
materials.

Otherwise, it's not C++ you're teaching but, rather, a language that
looks a lot like C++, but isn't.

From what little I saw I don't think the aim is to teach a particular
language, but programming in general.

Otherwise, I agree 100%.

Also that the code in the book needs to be reworked to standard C++.

 

[Default User]

All the programs can be compiled with the free Borland C++ 5.5
compiler. It is true that a few programs in the last chapters
require a statement like using namespace std ; in order to
compile them with Microsoft C++ or with Unix/Linux compilers.

With so many good books that DO conform to the Standard (i.e. Koenig and
Moo), why would anyone bother with a book that is a mishmash of
standard, nonstandard and some downright incorrect usage?




Brian Rodenborn

 

[jeffc]

With so many good books that DO conform to the Standard (i.e. Koenig and
Moo)...

You meant, of course, "e.g., Koenig and Moo". As you said, there are many
books that do conform.

 

[Default User]

You meant, of course, "e.g., Koenig and Moo". As you said, there are many
books that do conform.

I did indeed.



Brian Rodenborn

 

[White Wolf]

I have spent about 7 years in writing the book.
I decided to use <iostream.h> instead of <iostream> because
that way I did not have to say using namespace std ;
at the beginning of every program. By dropping this statement
I wanted to make the first programs a little bit less
confusing for a beginner.

Do not top post. Thanks.

Those headers might be supported - or might not. The standard does not
require it. And to teach beginners to use an outdated version of the C++
headers is not really a good idea. I mean worse than that. It may take
years to get rid off that habbit.

Not to mention that the old iostreams (strings etc.) were *not* the same as
the new ones. There are fundamental differences between the old and the
new.

I just do not like the idea to teach outdated things to people as a skill.
I find it hardly justifiable if justifiable at all.

And honestly. The justification of leaving out using namespace std; strikes
me as either laziness or ignorance. Laziness is inexcusable in teaching.
And probably the word ignorance is too harsh, but I must say I could not
find any lighter description of the fact that someone thinks that the only
difference (what matters) between the old (never standard) headers and the
new ones is the namespace std.

Classic iostreams and classic string are very different from the old one.
Very.

Bjarne Stroustrup, Andrew Koenig, (IIRC) Francis Glassborow, Stanley B.
Lippman etc. could all solve to use the right headers. And Francis'es book
is a book which happens to use C++ to teach computer programming - but not
in itself is a C++ book as its main goal.

So in 2003 I find it inexcusable to teach a technique (to beginners), which
was outdated approx. 7 years ago. And I do that will all due respect to the
work placed into the book. But I had enough trouble constantly brainwashing
people to elminate Schildt contamination. I really do not need greenhorns
agruing: "but this must be correct! I have read it in a book, which was
published in 2003!"

 

[Alf P. Steinbach]

Do not top post. Thanks.

Those headers might be supported - or might not. The standard does not
require it. And to teach beginners to use an outdated version of the C++
headers is not really a good idea. I mean worse than that. It may take
years to get rid off that habbit.

Not to mention that the old iostreams (strings etc.) were *not* the same as
the new ones. There are fundamental differences between the old and the
new.

I just do not like the idea to teach outdated things to people as a skill.
I find it hardly justifiable if justifiable at all.

And honestly. The justification of leaving out using namespace std; strikes
me as either laziness or ignorance. Laziness is inexcusable in teaching.
And probably the word ignorance is too harsh, but I must say I could not
find any lighter description of the fact that someone thinks that the only
difference (what matters) between the old (never standard) headers and the
new ones is the namespace std.

Classic iostreams and classic string are very different from the old one.
Very.

Bjarne Stroustrup, Andrew Koenig, (IIRC) Francis Glassborow, Stanley B.
Lippman etc. could all solve to use the right headers. And Francis'es book
is a book which happens to use C++ to teach computer programming - but not
in itself is a C++ book as its main goal.

Agreed so far.

So in 2003 I find it inexcusable to teach a technique (to beginners), which
was outdated approx. 7 years ago.

Let's say by the end of 1999. I don't think it's fair to criticise someone
for not using standard headers _before_ the standard (late 1997). Yes? ;-)

And I do that will all due respect to the
work placed into the book. But I had enough trouble constantly brainwashing
people to elminate Schildt contamination. I really do not need greenhorns
agruing: "but this must be correct! I have read it in a book, which was
published in 2003!"

I recently had to look up again Bruce Eckel's online book, highly recommended
by ACCU. Now Bruce doesn't walk into that same trap, but he _does_ give the
impression that

#include <iostream.h>

is equivalent to

#include <iostream>
using namespace std;

In fact, he uses (or used) that as an example, choosing one of the few headers
where such equivalence does not hold, and where the old-time header isn't even
in the standard, without mentioning it.

He goes on to teach pointers by way of the C viewpoint, and so on.

Perhaps I or you or someone else knowledgeable should write a more ACCUrate
review of that book -- in light of _current_ practice (I think the highly
praising one was written by Francis, but check the year of the review)...


Cheers,

- Alf

 

[Attila Feher]

Alf P. Steinbach wrote:
[SNIP]

Let's say by the end of 1999. I don't think it's fair to criticise
someone for not using standard headers _before_ the standard (late
1997). Yes? ;-)

AFAIU the book was started to be written at that time and not finished.

I recently had to look up again Bruce Eckel's online book, highly
recommended by ACCU. Now Bruce doesn't walk into that same trap, but
he _does_ give the impression that

#include <iostream.h>

is equivalent to

#include <iostream>
using namespace std;

Upto a certain degree... Like in a Hello World.

In fact, he uses (or used) that as an example, choosing one of the
few headers where such equivalence does not hold, and where the
old-time header isn't even in the standard, without mentioning it.

That is Not Good [TM].

He goes on to teach pointers by way of the C viewpoint, and so on.

What does that mean? (Sorry, my English.)

Perhaps I or you or someone else knowledgeable should write a more
ACCUrate review of that book -- in light of _current_ practice (I
think the highly praising one was written by Francis, but check the
year of the review)...

I am sure if you bring this to Bruce's attention he will fix it. I am also
sure that if you bring that into Francis'es attention he will... well, I am
only sure about that he will get back to you. I am not sure if he is
willing to revise his review.

 

[Kari Laitinen]

[Do not top-post (see the FAQ) -- rearranged]

I have spent about 7 years in writing the book.
I decided to use <iostream.h> instead of <iostream> because
that way I did not have to say using namespace std ;
at the beginning of every program. By dropping this statement
I wanted to make the first programs a little bit less
confusing for a beginner.

Seven years ago, in 1996, that made very much sense. Even a year or
two after the standard (which appeared late 1997) authors had to make
the hard choice between practically non-compilable standard-conforming
code, compilable non-standard code, or ugly hybrid solutions with "remove
this if your compiler doesn't support namespaces" and the like. Today,
however, most compilers conform to the then not yet existing standard wrt.
this area, which means that some/many of the programs may not even compile,
which is certainly _very_ confusing to the beginner... ;-)

See [http://www.utvikling.com/cppfaq/01/03/index.html] for directions on
obtaining standard-conforming free C++ compilers (this is in Norwegian).

Perhaps it's possible to automate the conversion of most programs?

OK. After reading all this criticism, I have decided to
replace

#include <iostream.h>

with

#include <iostream>
using namespace std ;

in every program of the book, and update the book.
Because this book is made with print-of-demand technology, it is not
a tremendous trouble to make a new version of it.

 

[Attila Feher]

Kari Laitinen wrote:
[SNIP]

OK. After reading all this criticism, I have decided to
replace

#include <iostream.h>

with

#include <iostream>
using namespace std ;

in every program of the book, and update the book.
Because this book is made with print-of-demand technology, it is
not a tremendous trouble to make a new version of it.

Cool!

That also means that if people do review your book fully and find typos or -
god forbid - mistakes, you will be able to add fixes to the book pretty
fast. That is cool.

 

[Alf P. Steinbach]

What does that mean? (Sorry, my English.)

E.g., in chapter 4 he (Bruce Eckel) starts off with a C-like library
that emulates some aspects of std::vector, called CStash, without
mentioning std::vector. CStash is gradually transformed into something
that is purportedly the C++ way. Example usage of the final version:


//: C04:CppLibTest.cpp
//{L} CppLib
// Test of C++ library
#include "CppLib.h"
#include "../require.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;

int main() {
Stash intStash;
intStash.initialize(sizeof(int));

-- no constructors (objects have been discussed)
-- sizeof(int)? Presumbaly element size. Ugh.


for(int i = 0; i < 100; i++)
intStash.add(&i);
for(int j = 0; j < intStash.count(); j++)
cout << "intStash.fetch(" << j << ") = "
<< *(int*)intStash.fetch(j)

-- cast, and to top it off, C-style cast


<< endl;
// Holds 80-character strings:
Stash stringStash;
const int bufsize = 80;

-- holds 79-character strings


stringStash.initialize(sizeof(char) * bufsize);

-- oh dear


ifstream in("CppLibTest.cpp");
assure(in, "CppLibTest.cpp");
string line;
while(getline(in, line))
stringStash.add(line.c_str());

int k = 0;
char* cp;

-- informative variable names


while((cp =(char*)stringStash.fetch(k++)) != 0)

-- while instead of for
-- subtle side effects (postincrement, assignment) in expressions


cout << "stringStash.fetch(" << k << ") = "
<< cp << endl;
intStash.cleanup();

-- never heard of destructors


stringStash.cleanup();

-- ditto

} ///:~