By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,788 Members | 1,443 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,788 IT Pros & Developers. It's quick & easy.

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

P: n/a

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
Jul 19 '05 #1
Share this Question
Share on Google+
24 Replies

P: n/a
On Thu, 11 Sep 2003 14:25:02 +0300, Kari Laitinen <ka***********@oamk.fi> wrote:

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.

Jul 19 '05 #2

P: n/a
On Thu, 11 Sep 2003 14:25:02 +0300, Kari Laitinen <ka***********@oamk.fi> wrote:

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

--
Sam Holden

Jul 19 '05 #3

P: n/a

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.

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.

Jul 19 '05 #4

P: n/a

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.
Jul 19 '05 #5

P: n/a
[Do not top-post (see the FAQ) -- rearranged]

On Thu, 11 Sep 2003 15:08:47 +0300, Kari Laitinen <ka***********@oamk.fi> wrote:
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.


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?

Jul 19 '05 #6

P: n/a

"Kari Laitinen" <ka***********@oamk.fi> wrote in message
news:3F***************@oamk.fi...

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.
Jul 19 '05 #7

P: n/a
> ... 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.
Jul 19 '05 #8

P: n/a
On 11 Sep 2003 14:47:56 GMT, "Oliver S." <Fo*******@gmx.net> wrote:
... 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.


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.

Jul 19 '05 #9

P: n/a
Kari Laitinen wrote:
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

--
Artie Gold -- Austin, Texas

Jul 19 '05 #10

P: n/a
On Thu, 11 Sep 2003 16:15:47 GMT, Artie Gold <ar*******@austin.rr.com> wrote:
Kari Laitinen wrote:
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.


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

Jul 19 '05 #11

P: n/a
Kari Laitinen wrote:

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
Jul 19 '05 #12

P: n/a

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...
Kari Laitinen wrote:

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


You meant, of course, "e.g., Koenig and Moo". As you said, there are many
books that do conform.
Jul 19 '05 #13

P: n/a
jeffc wrote:

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...

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.


I did indeed.

Brian Rodenborn
Jul 19 '05 #14

P: n/a
Kari Laitinen wrote:
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!"

--
WW aka Attila
Jul 19 '05 #15

P: n/a
On Fri, 12 Sep 2003 06:42:29 +0300, "White Wolf" <wo***@freemail.hu> wrote:
Kari Laitinen wrote:
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.


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

Jul 19 '05 #16

P: n/a
Alf P. Steinbach wrote:
[SNIP]
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? ;-)


AFAIU the book was started to be written at that time and not finished. :-)
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;


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.

--
Attila aka WW
Jul 19 '05 #17

P: n/a
"Alf P. Steinbach" wrote:

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

On Thu, 11 Sep 2003 15:08:47 +0300, Kari Laitinen <ka***********@oamk.fi> wrote:
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.


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.
Jul 19 '05 #18

P: n/a
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.

--
Attila aka WW
Jul 19 '05 #19

P: n/a
On Fri, 12 Sep 2003 12:07:01 +0300, "Attila Feher" <at**********@lmf.ericsson.se> wrote:
Alf P. Steinbach wrote:
He goes on to teach pointers by way of the C viewpoint, and so on.


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

} ///:~

Jul 19 '05 #20

P: n/a
"Kari Laitinen" <ka***********@oamk.fi> wrote in message
news:3F***************@oamk.fi...
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.


Does this mean that book versions are soon to have the same kind of
versioning that we see on Microsoft products. Example: "I was referring to
the 6.1027.3 version of the book."
--
Gary
Jul 19 '05 #21

P: n/a
Alf P. Steinbach wrote:
On Fri, 12 Sep 2003 12:07:01 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:
Alf P. Steinbach wrote:
He goes on to teach pointers by way of the C viewpoint, and so on.


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:

[SNIP]

Oh my. Oh my. After reading that code I have to go and confess. And I am
still not sure if I will not go to hell for this.

--
WW aka Attila
Jul 19 '05 #22

P: n/a
Gary Labowitz wrote:

"Kari Laitinen" <ka***********@oamk.fi> wrote in message
news:3F***************@oamk.fi...
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.


Does this mean that book versions are soon to have the same kind of
versioning that we see on Microsoft products. Example: "I was referring to
the 6.1027.3 version of the book."
--
Gary


It try to avoid too many versions of the book. It's not
that simple to make new versions, and it costs me money.
However, this book can be changed more easily than
a book printed with the conventional offset printing
technology.
Jul 19 '05 #23

P: n/a
Kari Laitinen wrote:
I have written a computer programming book that uses C++.
The book is for beginners in the field of computer programming,

[SNIP]

Hi again,

Running a looong ZIPping and looking at your example book pages in the
meanwhile. I will put my little suggestions here, some might be silly,
others more silly.

Page 12: you talk about "output stream" but does not really say what is a
stream. Unless you want the readers to wonder about what is a stream
instead of concentrating on the text I suggest that you include there some
sort of short description the concept. A really short one, just to give an
rough idea, maybe with a picture.

Page 13, example program, ballon: "Pairs of braces {} are used to delimit
the program statements in C++." This is simply not true. Braces are used
to *group* the statements and the semicolon is used to delimit them!

Page 15 example program. It is not a C++ issue, rather a usability issue.
The given program writes: Please type in an integer and when I did type in
one, I have pressed the enter it asks again the *same*. This confuses users
the best. "But I just did give you an integer!" I suggest to change the
second printout to something a bit different.

Same page: the description of the main function is confusing. It tries to
discuss functions *and* the restriction on main to return int at the same
time, and ends up suggesting that "In most of our programs, we will have a
function named main() whose type is int." While this is A OK, it does not
say that its type is *always* int. One might understand it as: we might
have a main or might not and it might have the type int or might not.
According to the standard language it must have the type int.

Well, that's all for today. I hope it helps. :-)

--
Attila aka WW
Jul 19 '05 #24

P: n/a
Attila Feher wrote:

Kari Laitinen wrote:
I have written a computer programming book that uses C++.
The book is for beginners in the field of computer programming,

[SNIP]

Hi again,

Running a looong ZIPping and looking at your example book pages in the
meanwhile. I will put my little suggestions here, some might be silly,
others more silly.

Page 12: you talk about "output stream" but does not really say what is a
stream. Unless you want the readers to wonder about what is a stream
instead of concentrating on the text I suggest that you include there some
sort of short description the concept. A really short one, just to give an
rough idea, maybe with a picture.

Page 13, example program, ballon: "Pairs of braces {} are used to delimit
the program statements in C++." This is simply not true. Braces are used
to *group* the statements and the semicolon is used to delimit them!

Page 15 example program. It is not a C++ issue, rather a usability issue.
The given program writes: Please type in an integer and when I did type in
one, I have pressed the enter it asks again the *same*. This confuses users
the best. "But I just did give you an integer!" I suggest to change the
second printout to something a bit different.

Same page: the description of the main function is confusing. It tries to
discuss functions *and* the restriction on main to return int at the same
time, and ends up suggesting that "In most of our programs, we will have a
function named main() whose type is int." While this is A OK, it does not
say that its type is *always* int. One might understand it as: we might
have a main or might not and it might have the type int or might not.
According to the standard language it must have the type int.

Well, that's all for today. I hope it helps. :-)

--
Attila aka WW


Thank you for those comments. At least 50 % of them result in
a change in the book.

I hope people will keep sending you those long ZIP files. :-)
Jul 19 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.