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

If you're new and need a book

P: n/a
http://www.icarusindie.com/Literature/ebooks/

Rather than advocating wasting money on expensive books for beginners,
here's my collection
of ebooks that have been made freely available on-line by their authors.
There are lots of them out there but this selection cuts out the junk.

If you know of any other good books that are freely available please post a
link to them here and I'll consider adding them to the site.

There's really no reason for a new programmer to pay for anything. You will
need to be quite a proficient programmer before you really need to fork out
the cash for an expensive book.

Ben Kucenski
www.icarusindie.com
Jul 22 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Carter Smith wrote:
http://www.icarusindie.com/Literature/ebooks/

Rather than advocating wasting money on expensive books for beginners,
here's my collection
of ebooks that have been made freely available on-line by their authors.
There are lots of them out there but this selection cuts out the junk.
No, it doesn't. The books are outdated, at least the C++ ones I took
a look at. I would recommend every newbie to actually search the Web
and sieve through the junk to find the most up-to-date editions of the
books.
[...]


V
Jul 22 '05 #2

P: n/a
Victor Bazarov wrote:

Carter Smith wrote:
http://www.icarusindie.com/Literature/ebooks/

Rather than advocating wasting money on expensive books for beginners,
here's my collection
of ebooks that have been made freely available on-line by their authors.
There are lots of them out there but this selection cuts out the junk.


No, it doesn't. The books are outdated, at least the C++ ones I took
a look at. I would recommend every newbie to actually search the Web
and sieve through the junk to find the most up-to-date editions of the
books.

Well, he has Thinking in C++ 2nd referenced, I believe that's decent.
I'd go directly to the author's site for it though:
http://mindview.net/Books


Brian Rodenborn
Jul 22 '05 #3

P: n/a

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:0zWWc.23594$L94.10276@fed1read07...
"old" programming books are no more outdated than last year's dictionary or last years algebra text book. Especially with C++ which had been
standardized before many newbies had been born. A book that teaches how to use classes and other core OO topics or even just how to use the basics of
the language will never go out of date.
Up to date books are very relavant.

In the "Teach Yourself C++ in 21 Days", that you have listed, the very first
program is this:

#include <iostream.h>
int main()
{
cout << "Hello World!\n";
return 0;
}

This program will *not* compile on many compilers, including the latest
Visual C++ compilers that may be popular with many beginners (now that it is
a free download). Imagine a beginner who gets this book and sees that the
simplest program doesn't even compile. What then?
C++ has added new ways to do the same old same old and there's no harm in
doing the same old same old the same old way. Because it still works.


No it doesn't. See above.

- Paul

Jul 22 '05 #4

P: n/a
"Paul" <pa**@paul.com> wrote in message news:Ts_Wc.6572$rT1.2406@trndny02...

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:0zWWc.23594$L94.10276@fed1read07...
"old" programming books are no more outdated than last year's dictionary or
last years algebra text book. Especially with C++ which had been
standardized before many newbies had been born. A book that teaches how

to
use classes and other core OO topics or even just how to use the basics of the language will never go out of date.


Up to date books are very relavant.

In the "Teach Yourself C++ in 21 Days", that you have listed, the very

first program is this:

#include <iostream.h>
int main()
{
cout << "Hello World!\n";
return 0;
}

This program will *not* compile on many compilers, including the latest
Visual C++ compilers that may be popular with many beginners (now that it is a free download). Imagine a beginner who gets this book and sees that the
simplest program doesn't even compile. What then?
C++ has added new ways to do the same old same old and there's no harm in doing the same old same old the same old way. Because it still works.


No it doesn't. See above.


While I disagree totally with Paul (I figured him for a flamer), it turns
out this does compile with g++ using Dev-Cpp, and with VC++, 6.0 and .NET.
Too bad, since they are all covering the .h header. There is a deprecattion
message from g++. (Oh, I did add std:: to that cout, but I figure you were
commenting on the .h header. Maybe not!)
--
Gary
Jul 22 '05 #5

P: n/a
"Carter Smith" <ne**@email.icarusindie.com> wrote in message news:<0zWWc.23594$L94.10276@fed1read07>...
"old" programming books are no more outdated than last year's dictionary or
last years algebra text book.
This simply isn't true.

Many older books on C++ had all sorts of problems relative to the
language as it stands today. For a few obvious examples:

1) assuming that new returns a null pointer upon failure.
2) making no attempt at exception safety.
3) advocating inheritance when templates would be more appropriate.
4) advocating classes that imitate superior ones in the library.

The bottom line is pretty simple: even among new books, there's a
distressingly small percentage that teach the language is it exists
today. As the books get older, that percentage diminishes very
quickly.
Especially with C++ which had been
standardized before many newbies had been born. A book that teaches how to
use classes and other core OO topics or even just how to use the basics of
the language will never go out of date.
C++ has not been standardized for a particularly long time, and books
as a whole have lagged well behind the standard. There ARE excellent
books on things like OO analysis (E.g. Booch) algorithms (going back
at least as far as Knuth) and so on, but when it comes to the language
proper, few older books retain a great deal of value.
C++ has added new ways to do the same old same old and there's no harm in
doing the same old same old the same old way. Because it still works.
Quite the contrary. Just for one obvious example, the minute exception
handling was added to the language, MANY of the old ways of doing
things were instantly broken. Teaching people to write code that isn't
exception safe is actively harmful.

[ ... ]
Should we ignore that core theory of geometry simply because it's thousands
of years old and new theories related to geometry have come about?
Of course not -- but the simile is poor at best. In the case of
geometry, the definition of what's being taught is old. In the case of
C++, the definition of the language has NOT existed for thousands of
even dozens of years. Worse, most books did not (even attempt to)
follow the standard as soon as it was approved.

There are two basic problems here. First of all, many new books aren't
entirely new -- they're revisions of older books. Unfortunately for
that, C++ has changed enough, quickly enough, that most of revisions
aren't really adequate to address the changes that have taken place.
In many cases it appears that _several_ revisions will be necessary
before the books catch up with the current standard.

Second, especially in introductory books, the author faces a serious
problem at best: the market forces him to teach the language as
defined by mainstream compilers rather than as defined by the
standard. Until recently, and to a lesser degree even now, that meant
many books were taught C++ within the restrictions imposed by MS
Visual C++ 6.0 (which predates the standard).

Even after the author and publisher agree that an up-to-date book is
needed, it can easily take a year of serious work to write a good
book, and months after that to get it published.
You
can't get much more outdated than 2000 years and yet here we are still
teaching it and relying on it.
This assumes that being dated depends purely on age, which clearly
isn't true.

Some parts of geometry haven't change radically since then, but
medical practices, knowledge of chemistry, physics, etc. certainly
have. If, however, you want to restrict yourself to what the Greeks
knew about computer programming (i.e. nothing) feel free to do so --
but don't expect everybody else to share your enthusiasm for
ignornace.
The STL and templates are not without controversy. It's not like everyone
just assumes they're the best thing ever. If you want to learn how to use
that stuff with "up to date" books then that's fine. There are entire books
dedicated the the STL and templates. For my audience I go with the basic
OOP style. If you're an advanced programmer and insist on templates and
whatnot then that's your choice. But it's not my target audience.


Templates, for one example, are nearly unavoidable except by the very
most advanced programmers. Just for an obvious example, the minute you
write a hello world program that writes to cout, you've used a
templated class. That class is defined in such a way that it can throw
exceptions.

The fact is, that in C++ you can't avoid templates and exceptions and
so on. If you ignore them, you write broken code. If you teach others
to ignore them, you teach them to write broken code.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #6

P: n/a
> 1) assuming that new returns a null pointer upon failure.

That's syntax. I always check to see if a pointer is not zero before using
it and default it to 0. Not so surprisingly I've never had a problem with
it. That statement also assumes that you should use "new." If you're doing
real time programming you simply can't use new and delete because they're
horribly slow. A* relies heavily on allocating and deleting memory and with
new and delete you'll never get it fast enough unless you're only covering
short distances. This is what most tutorials for A* do which is why the
authors don't bother to point out that their implementation is horribly
inefficient. It looks fast to them. It's still necessary to know about
malloc and free so that you can make an informed decision about which to
use. You can't just rely on brute force Ghz all the time.
2) making no attempt at exception safety.
Syntax. You don't get exception handling in many languages. It's better to
write code that crashes when it's broken so you can eliminate the bad code
or bad cases that cause exception errors rather than relying on additional
code to serve as a crutch for other code. That's what debug is for.
3) advocating inheritance when templates would be more appropriate.
That's a syntatical debate. Many languages don't have templates.
4) advocating classes that imitate superior ones in the library.
That's an educational debate. Do you want to know how something works or
just use a magic black box? It's often the case that it's a bad idea to use
an existing library because libraries are not consistant across languages.
Long ago I refused to use C because it relied on libraries. I could do
better graphics with more colors but everything was hidden so it was
pointless. I wanted to know how things worked. I learned a lot more by
doing things the hard way. I've done a few dozen tutorials on software
rendering already and I'm far from done. Sure, I could do a bunch of
lessons in OpenGL or DirectX but that's boring and not too educational. The
math used for software renderering rears it's ugly head outside the realm of
graphics as well. So you can't hide behind OpenGL and DirectX forever.
The bottom line is pretty simple: even among new books, there's a
distressingly small percentage that teach the language is it exists
today. As the books get older, that percentage diminishes very
quickly.


And yet we still use books filled with algorithms that were first written
decades ago. Some before there were even computers.

A lot of people value syntax above all when it comes to languages. And this
is why we have students who learn Java who are then completely lost when
they're presented with C/C++. Or the other way around. It's a very rare
programmer who only uses one language their entire career. They're also not
particularly valuable to an employer.

The concepts taught in older books are just as revelavent now as they were
when they were first written. Not every language has templates and the STL
so at some point you need to know how things work on a lower level. If you
intend to get into console programming you'll probably need assembly as well
since not every game system runs at 3Ghz. Which is why my lessons on
software rendering will eventually go to assembly.

Mark Twain said that people who could spell words more than one way were
more intelligent that people who could only spell them one way. It's the
same thing with programming. You still need to know how to do things The
Old Way(tm) so you can make informed decisions about which is The Better
Way(tm) to do something. You can't just assume that the New Way is The
Better Way.

Ben Kucenski
www.icarusindie.com


Jul 22 '05 #7

P: n/a
I was going to say, if Paul actually knew C++ he would have known that the
code would compile just by looking at it. It would have taken all of two
minutes to test his theory before making his false claim on a permanent
venue.

Well, that's one less person's posts I need to consider. Usually when
people post bad code they post code that doesn't work and claim it does.
This is a new one.

Ben Kucenski
www.icarusindie.com
"Gary Labowitz" <gl*******@comcast.net> wrote in message
news:Oo********************@comcast.com...
"Paul" <pa**@paul.com> wrote in message news:Ts_Wc.6572$rT1.2406@trndny02...

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:0zWWc.23594$L94.10276@fed1read07...
"old" programming books are no more outdated than last year's
dictionary
or
last years algebra text book. Especially with C++ which had been
standardized before many newbies had been born. A book that teaches
how to
use classes and other core OO topics or even just how to use the
basics of the language will never go out of date.
Up to date books are very relavant.

In the "Teach Yourself C++ in 21 Days", that you have listed, the very

first
program is this:

#include <iostream.h>
int main()
{
cout << "Hello World!\n";
return 0;
}

This program will *not* compile on many compilers, including the latest
Visual C++ compilers that may be popular with many beginners (now that it is
a free download). Imagine a beginner who gets this book and sees that
the simplest program doesn't even compile. What then?
C++ has added new ways to do the same old same old and there's no harm

in doing the same old same old the same old way. Because it still works.


No it doesn't. See above.


While I disagree totally with Paul (I figured him for a flamer), it turns
out this does compile with g++ using Dev-Cpp, and with VC++, 6.0 and .NET.
Too bad, since they are all covering the .h header. There is a

deprecattion message from g++. (Oh, I did add std:: to that cout, but I figure you were commenting on the .h header. Maybe not!)
--
Gary

Jul 22 '05 #8

P: n/a
[Do not troll, do not top-post, do not break lines in quoting, do not quote
signatures, do not post under false name, etc. ad nauseam, rearranged]

* Carter Smith, signing with "Ben Kucenski www.icarusindie.com":
* Gary Labowitz:
* Paul:
* Carter Smith:
> "old" programming books are no more outdated than last year's
> dictionary or last years algebra text book. Especially with C++
> which had been standardized before many newbies had been born. A
> book that teaches how to use classes and other core OO topics or
> even just how to use the basics of the language will never go out
> of date.

Up to date books are very relavant.

In the "Teach Yourself C++ in 21 Days", that you have listed, the very
first program is this:

#include <iostream.h>
int main()
{
cout << "Hello World!\n";
return 0;
}

This program will *not* compile on many compilers, including the latest
Visual C++ compilers that may be popular with many beginners (now that
it is a free download). Imagine a beginner who gets this book and sees
that the simplest program doesn't even compile. What then?

> C++ has added new ways to do the same old same old and there's no harm
> in doing the same old same old the same old way. Because it still works.

No it doesn't. See above.
While I disagree totally with Paul (I figured him for a flamer), it turns
out this does compile with g++ using Dev-Cpp, and with VC++, 6.0 and .NET.
Too bad, since they are all covering the .h header. There is a
deprecattion message from g++. (Oh, I did add std:: to that cout, but I
figure you were commenting on the .h header. Maybe not!)

I was going to say, if Paul actually knew C++ he would have known that the
code would compile just by looking at it. It would have taken all of two
minutes to test his theory before making his false claim on a permanent
venue.


You are wrong, and Paul is correct.

Well, that's one less person's posts I need to consider.


Here you're right.

Plonk.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #9

P: n/a
I shouldn't feed the troll, but....

Carter Smith wrote:
1) assuming that new returns a null pointer upon failure.

That's syntax.


Wrong. A conforming compiler throws std::bad_alloc on failure

2) making no attempt at exception safety.

Syntax. You don't get exception handling in many languages.

See above.
3) advocating inheritance when templates would be more appropriate.

That's a syntatical debate. Many languages don't have templates.

Here he may have a point. If the point is to teach inheritance then use
inheritance. However see the words *more appropriate*
4) advocating classes that imitate superior ones in the library.

That's an educational debate. Do you want to know how something works or
just use a magic black box?

Again, he may have a point here. Over my career, I certainly have
implemented most of the classes in the STL, and knowing how they work
helps when I *do* have to design my own structures. However, this is
generally work for a data structures and algorighms class.
Jul 22 '05 #10

P: n/a
Carter Smith wrote:

"old" programming books are no more outdated than last year's dictionary or
last years algebra text book. Especially with C++ which had been
standardized before many newbies had been born.


Please don't top-post.
C++ was standardized in 1998. Those would be some pretty precocious
newbies.


Brian Rodenborn
Jul 22 '05 #11

P: n/a
"Carter Smith" <ne**@email.icarusindie.com> wrote in message news:<0zWWc.23594$L94.10276@fed1read07>...
"old" programming books are no more outdated than last year's dictionary or
last years algebra text book. Especially with C++ which had been
standardized before many newbies had been born.
You mean "many newbies" were born after 1998? Wow, I guess a lot of C++
newbies are more precocious than I realized. :-)
A book that teaches how to
use classes and other core OO topics or even just how to use the basics of
the language will never go out of date.


Never is a long time. Homer's epics have lasted about 2800 years so far,
Dante's works about 700, Shakespeare's a little over 400. That's about
as close as we humans get to immortality, but even they will go out of
date at some point -- when the human race becomes extinct, perhaps, or
when the universe itself comes to an end.

Seriously, there are some programming books that have lasted more than
a few years. However, books on programming languages are vulnerable to
changes in the languages themselves. C++ has changed considerably in
the last decade, and the accompanying techniques and best practices
have changed even more.
Jul 22 '05 #12

P: n/a
"Carter Smith" <ne**@email.icarusindie.com> wrote in message news:<YP2Xc.23718$L94.3435@fed1read07>...
1) assuming that new returns a null pointer upon failure.
That's syntax.


....and that's proof that you don't know the meaning the word "Syntax".

Syntax is the set of rules that govern what form legal statements in a
language.

Returning a null pointer clearly has nothing to do with syntax.

Syntactic issues should not be trivialized in any case: to do any
programming, one has to learn the syntax of the language to be used.
I always check to see if a pointer is not zero before using
it and default it to 0. Not so surprisingly I've never had a problem with
it. That statement also assumes that you should use "new."
No, it does not. It's a FACT that new is part of C++. Anybody who is
ignorant of new is clearly ignorant of quite a substantial portion of
C++. Anybody who is ignorant of dynamic allocation in generaly is
ignorant of a substantial portion of programming.
If you're doing
real time programming you simply can't use new and delete because they're
horribly slow.
Quite the contrary -- there are dynamic allocators that are perfectly
capable of providing real-time response.

In any case, "slow" and "real-time" aren't necessarily mutually
exclusive. In a real-time system, speed must be predictable and
dependable. In many cases, you forego the highest average speed in
favor of something that has more predictable speed.

Just for example, consider two dictionaries, one based on a balanced
tree and another based on hashing. In a typical situation the
hashing-based system will be substantially faster -- but also
substantially less suited to real-time use.

The reason is simple: hashing has an expected complexity of O(k), but
a worst case complexity of O(N). A balanced tree has an expected
complexity of O(lg2 N) and a worst case something like O(2 lg2 N).

Getting back to dynamic allocation we have a similar situation. Just
for one example, one typical optimization of the buddy-system
allocator is lazy merging of freed blocks. This improves speed on
average, but hurts predictability. An "unoptimized" buddy-system
allocator has fairly predictable response -- it does a maximum of
Lg2(N) block splits during an allocation, and a merges a maximum of
three blocks when freeing memory. As such, validating a buddy-system
allocator for real-time use is entirely within the realms of
possibility.
A* relies heavily on allocating and deleting memory and with
new and delete you'll never get it fast enough unless you're only covering
short distances. This is what most tutorials for A* do which is why the
authors don't bother to point out that their implementation is horribly
inefficient. It looks fast to them. It's still necessary to know about
malloc and free so that you can make an informed decision about which to
use. You can't just rely on brute force Ghz all the time.
You seem to lack not only knowledge, but common sense as well.
Knowledge of how new works certainly does NOT imply relying on "brute
force GHz all the time" or anything like it.
2) making no attempt at exception safety.


Syntax.


Wrong again.
You don't get exception handling in many languages.
We were talking about C++. If you want to discuss some other language,
you're clearly in the wrong newsgroup. Even if other languages were
topical, you can't claim to learn programming in general by ignoring
things because they're not present in all languages -- after all, the
original BASIC lacked such things as real functions, while some
functional languages lack assignment. If you refuse to learn anything
that isn't present in both, you're left knowing nothing.
It's better to
write code that crashes when it's broken so you can eliminate the bad code
or bad cases that cause exception errors rather than relying on additional
code to serve as a crutch for other code. That's what debug is for.
Clearly you lack any clue of what exception handling is for.
3) advocating inheritance when templates would be more appropriate.


That's a syntatical debate. Many languages don't have templates.


The difference between templates and inheritance goes far beyond
syntax. Again, if you're interested in a language that lacks
templates, you're clearly in the wrong newsgroup. Again, learning more
than one language is no excuse here either: Ada and Java (for a couple
of examples) provide facilities similar to C++ templates.
4) advocating classes that imitate superior ones in the library.


That's an educational debate. Do you want to know how something works or
just use a magic black box? It's often the case that it's a bad idea to use
an existing library because libraries are not consistant across languages.


"Across languages" is meaningless in a newsgroup devoted exclusively
to C++. In any case, I haven't said anything about people not learning
what would be necessary to write a string class, a matrix class, etc.
Most such things, however, involve a great deal of drudgery from which
there is little real learning. Worse, the books I'm thinking of don't
even use them for real study in themselves -- they simply included
them once upon a time when C++ lacked them, and now the continue to
use them, even though they're clearly obsolete.
Long ago I refused to use C because it relied on libraries. I could do
better graphics with more colors but everything was hidden so it was
pointless. I wanted to know how things worked. I learned a lot more by
doing things the hard way. I've done a few dozen tutorials on software
rendering already and I'm far from done. Sure, I could do a bunch of
lessons in OpenGL or DirectX but that's boring and not too educational. The
math used for software renderering rears it's ugly head outside the realm of
graphics as well. So you can't hide behind OpenGL and DirectX forever.
Apparently the C++ standard library can be added to the list of areas
of which you're grossly ignorant -- neither DirectX nor OpenGL is
included in the standard library.

In any case, I haven't suggested enforcing ignorance of any subject.
If somebody wants to study what's in the library in tremendous detail,
more power to them. If, however, they insist on a book that pushes a
string class (or whatever) that's now obsolete, and (worse) was a
piece of crap even when it was new, that's a whole different story.
The bottom line is pretty simple: even among new books, there's a
distressingly small percentage that teach the language is it exists
today. As the books get older, that percentage diminishes very
quickly.


And yet we still use books filled with algorithms that were first written
decades ago. Some before there were even computers.


I'm starting to think this must be a troll: you don't really expect us
to belive that you're such a complete idiot that you don't recognize
the difference between an algorithm and a language do you?
A lot of people value syntax above all when it comes to languages. And this
is why we have students who learn Java who are then completely lost when
they're presented with C/C++. Or the other way around. It's a very rare
programmer who only uses one language their entire career. They're also not
particularly valuable to an employer.
It's generally better to know "syntax" (or nearly any other word)
means before throwing it around so much. In any case, learning C++
well is hardly a bar to learning another language -- quite the
opposite; every feature of any one language is almost certain to have
a counterpart in some other language. As such, the better you learn
one language the more prepared you are to learn other languages AND to
start to make the connections that lead to an overall understanding.
Limiting the student's view of each language tends to enforce the
notion that each is unique unto itself.
The concepts taught in older books are just as revelavent now as they were
when they were first written.
You can repeat that as often as you want, but it's just NOT TRUE. Just
for example, I have one old book that goes into exhaustive (and
exhausting) detail about how to design constructors without exception
handling. Offhand, I can't think of ANY current language to which such
a discussion would apply. It was only ever meaningful by accident.
Not every language has templates and the STL
so at some point you need to know how things work on a lower level.
Which doesn't mean you need to remain ignorant of how they work at a
higher level. Learning templates (for example) does not suddenly
remove all knowledge of how to program without templates. Certainly
nobody can learn C++ using ONLY templates, without any other code. As
such, your argument is vacuous at best, and shows that you're either
ignorant of the subject matter or being deliberately decietful.
If you
intend to get into console programming you'll probably need assembly as well
since not every game system runs at 3Ghz. Which is why my lessons on
software rendering will eventually go to assembly.
You're welcome to write tutorials in any language you choose -- though
given the ignorance you've displayed so far, I can hardly imagine your
writing an assembly language tutorial that was worth much. I would
note, however, that regardless of how good or bad it is, a tutorial on
assembly language won't be topical here.
Mark Twain said that people who could spell words more than one way were
more intelligent that people who could only spell them one way. It's the
same thing with programming. You still need to know how to do things The
Old Way(tm) so you can make informed decisions about which is The Better
Way(tm) to do something. You can't just assume that the New Way is The
Better Way.


I, at least, have not advocated any such thing. If somebody is going
to learn C++, they need to learn the language as it exists today, not
as it existed 15 years ago. That does not denigrate the value of the
parts of the language that existed 15 years ago, nor the parts that
were "inherited" from C that existed 30 years ago.

Nonetheless, somebody who learns only about C as it existed 30 years
ago does NOT know C as it exists today, and somebody who knows C++ as
it existed 15 years ago does not know C++ as it exists today.

I'd also note that none of the concepts I mentioned is unique to C++,
or anything close to it. For example, some languages have exception
handling and others don't -- but exception handling has been around
quite a while now (at least as far back PL/I in the mid-1960's). A
pretty fair number of modern languages have exception handling --
enough that anybody who wants to know much about programming in
general needs to understand it.

The same is true to some degree or other with templates as well: while
there are certainly specific techniques that apply to C++ templates
but not (for example) to Ada generics, many ideas are common to both.

In the end, all of your arguments are self defeating: learning more of
one language does NOT prevent somebody from learning other languages
-- quite the contrary, it generally helps. The restricted subset you
seem to advocate will HURT a student's ability to learn other
languages and (especially) to learn programming as a whole rather than
viewing each language as its own little island. C++ is particularly
strong in this regard because it espouses enough paradigms and
provides enough features that a student who learns it well will be
provided with links to nearly any other language you can name -- but
restricting the view will reduce those connections.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #13

P: n/a

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:XU2Xc.23719$L94.11173@fed1read07...
I was going to say, if Paul actually knew C++ he would have known that the
code would compile just by looking at it. It would have taken all of two
minutes to test his theory before making his false claim on a permanent
venue.


First, I do know C++, since I've been using it for over 14 years.. Put that
in your smug pipe and smoke it.

Second, the new Visual C++ 7.x compiler will *not* compile the code. The
reason is that there is no such file any more as <iostream.h>. Try it an
see for yourself. As a matter of fact, the top rated web-site that answers
C++ questions (which I have been an active member of now for 5 years, and
one of its biggest contributors as far as answering C++ questions), gets
queries from beginners as to why their <iostream.h> laden code doesn't
compile with the latest Visual C++ compiler.

Get it now?

Jul 22 '05 #14

P: n/a
"Gary Labowitz" <gl*******@comcast.net> wrote in message >
While I disagree totally with Paul (I figured him for a flamer)


And what exactly do you disagree with? What version of NET? This will not
compile for VC++ 7.1, as noted by several that have that the compiler and
realize that <iostream.h> is no longer included.

The Comeau C++ compiler does the following with the program:
-----------------------------------------------------
Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"iostream.h", line 1: catastrophic error: #error directive:
<iostream.h> is not a Standard header, use <iostream> instead.
Note that when you change this header name, that identifiers such
as
"cout" and "endl" will no longer work, as they are in namespace
"std", so use be "std::cout" and "std::endl" respectively.
------------------------------------------
So again, what is a beginner who may be using a conforming ANSI C++ compiler
supposed to do when they get this or similar error message thrown at them
when they compile
their very first program? Reading the "Teach yourself C++" book will not
shed any light
on how to fix this problem.

Jul 22 '05 #15

P: n/a
Paul wrote:
Second, the new Visual C++ 7.x compiler will *not* compile the code. The
reason is that there is no such file any more as <iostream.h>. Try it an
see for yourself. As a matter of fact, the top rated web-site that
answers C++ questions (which I have been an active member of now for 5
years, and one of its biggest contributors as far as answering C++
questions), gets queries from beginners as to why their <iostream.h> laden
code doesn't compile with the latest Visual C++ compiler.

Get it now?


And there's nothing wrong about that either. I assume you will agree here?
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B.S.

Jul 22 '05 #16

P: n/a

"Carter Smith" <ne**@email.icarusindie.com> wrote in message news:YP2Xc.23718$L94.3435@fed1read07...
1) assuming that new returns a null pointer upon failure.
That's syntax.


Actually, it's semantics. The syntax is identical.
I always check to see if a pointer is not zero before using
it and default it to 0. Not so surprisingly I've never had a problem with
it.
Obviously you're using non-conforming implementations or you've never run out of
memory. New throws an exception on failures.
That statement also assumes that you should use "new."
This I agree with, but for completely different reasons than you are
arguing. Most programmers use of new is WRONG. They are
better off using some variable of non-dynamic duration (to include
things that manage dynamic allocation internally such as vectors,
strings, and smart pointers).

Your performance arguments are spurious for 90% of reality. The
bigger issue is code correctness and maintainability. You can't throw
more GHz at a broken program to fix it.
2) making no attempt at exception safety.


Syntax. You don't get exception handling in many languages. It's better to
write code that crashes when it's broken so you can eliminate the bad code
or bad cases that cause exception errors rather than relying on additional
code to serve as a crutch for other code. That's what debug is for.


This is the most idiotic thing I've ever heard. And I wish you would look up
the meaning of "Syntax."
3) advocating inheritance when templates would be more appropriate.
That's a syntatical debate. Many languages don't have templates.


The name of this group is comp.lang.C++.
4) advocating classes that imitate superior ones in the library.


That's an educational debate. Do you want to know how something works or
just use a magic black box?


The difference is whether you're teaching the concept or teaching the language.
If you're teaching what a linked list is (i.e., you're educating the user in data structures)
then yes, show the implementation. If you're trying to teach someone effective
C++ program, you steer them towards use of std::list and iterators.

The problem is a lot of C++ texts are written by C programmers. They still
do mallocs (possibly updated to new) rather than using things like vectors
when appropriate. Likewise the persist in the abomination of char* as a string
type when it sucks at that use even in C.

Jul 22 '05 #17

P: n/a
"Paul" <pa**@paul.com> wrote in message
news:fxjXc.59716$3O2.48196@trndny07...
"Gary Labowitz" <gl*******@comcast.net> wrote in message >
And what exactly do you disagree with? What version of NET? This will not
compile for VC++ 7.1, as noted by several that have that the compiler and
realize that <iostream.h> is no longer included.


I disagreed that "language books don't get outdated."
Do chemistry books get outdated? Do physics books get outdated? Electronics?
ARRL handbooks?
I know they do. In what way do you think they don't?

So let's define: By outdated I mean not useful with regard to the
information contained, at the current time, with current materials, and for
the current needs of the user; but were once useful at another time, with
different materials, and for other needs.
This would mean that a book on programming the Z80B chip is outdated. But if
you have an old Franklin 2000 and want to play with it to write a memory RAM
disk program, it might be very useful. It's still outdated, though, and so
is the RAM disk program. And so is the Franklin 2000.
I had friends who publish little magazines with handset type on a hand
press. Is hand setting outdated?
--
Gary
Jul 22 '05 #18

P: n/a
"Paul" <pa**@paul.com> wrote in message news:GcjXc.16994$oD2.105@trndny08...

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:XU2Xc.23719$L94.11173@fed1read07...
I was going to say, if Paul actually knew C++ he would have known that the code would compile just by looking at it. It would have taken all of two minutes to test his theory before making his false claim on a permanent
venue.
<snip> Second, the new Visual C++ 7.x compiler will *not* compile the code. The
reason is that there is no such file any more as <iostream.h>. Try it an
see for yourself. As a matter of fact, the top rated web-site that answers C++ questions (which I have been an active member of now for 5 years, and
one of its biggest contributors as far as answering C++ questions), gets
queries from beginners as to why thei riostream.hladencodedoesn't
compile with the latest Visual C++ compiler.


I thought the bone of contention was the use of <iostream.h> so I (sorta)
automatically inserted std:: in front of the cout and tried the following
code in .NET (7.1.3088)

// t1.cpp : Defines the entry point for the console application.
//
#include <iostream.h>
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
std::cout << "Hello, World!\n";
return 0;
}

I hate all the MS stdafx stuff, but that was generated by the project
builder. The above code compiles and runs just fine. So?
Changing it to

#include <iostream.h>
#include "stdafx.h"
int main( )
{
std::cout << "Hello, World!\n";
return 0;
}

Still compiled and worked fine. [Now, how do I get rid of MS wanting
precompiled headers? OT OT OT OT!!!]
--
Gary
Jul 22 '05 #19

P: n/a
"Paul" <pa**@paul.com> wrote in message news:GcjXc.16994$oD2.105@trndny08...

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:XU2Xc.23719$L94.11173@fed1read07... <<snip>> Second, the new Visual C++ 7.x compiler will *not* compile the code. The
reason is that there is no such file any more as <iostream.h>. Try it an
see for yourself. As a matter of fact, the top rated web-site that answers C++ questions (which I have been an active member of now for 5 years, and
one of its biggest contributors as far as answering C++ questions), gets
queries from beginners as to why thei riostream.hladencodedoesn't
compile with the latest Visual C++ compiler.


Okay, got rid of precompiled headers (I'm lazy, but not that lazy) and now
<iostream.h> generates an error.
Shows what you get for using MS defaults.
--
Gary
Jul 22 '05 #20

P: n/a

"Gary Labowitz" <gl*******@comcast.net> wrote in message
news:3K********************@comcast.com...
"Paul" <pa**@paul.com> wrote in message news:GcjXc.16994$oD2.105@trndny08...

"Carter Smith" <ne**@email.icarusindie.com> wrote in message
news:XU2Xc.23719$L94.11173@fed1read07...
I was going to say, if Paul actually knew C++ he would have known that the code would compile just by looking at it. It would have taken all of two minutes to test his theory before making his false claim on a permanent venue.
<snip>
Second, the new Visual C++ 7.x compiler will *not* compile the code.

The reason is that there is no such file any more as <iostream.h>. Try it an see for yourself. As a matter of fact, the top rated web-site that

answers
C++ questions (which I have been an active member of now for 5 years, and one of its biggest contributors as far as answering C++ questions), gets
queries from beginners as to why thei riostream.hladencodedoesn't
compile with the latest Visual C++ compiler.


I thought the bone of contention was the use of <iostream.h> so I (sorta)
automatically inserted std:: in front of the cout and tried the following
code in .NET (7.1.3088)

// t1.cpp : Defines the entry point for the console application.
//
#include <iostream.h>
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
std::cout << "Hello, World!\n";
return 0;
}

I hate all the MS stdafx stuff, but that was generated by the project
builder. The above code compiles and runs just fine. So?


So, an implementation's behavior does not define correctness,
the language standard does.
The above ((even without the 'stdafx', with _tmain() changed to 'main(),
and _TCHAR changed to 'char'), is *not* standard compliant code.
Changing it to

#include <iostream.h>
#include "stdafx.h"
int main( )
{
std::cout << "Hello, World!\n";
return 0;
}

Still compiled and worked fine.
Same remarks as above.
[Now, how do I get rid of MS wanting
precompiled headers? OT OT OT OT!!!]


<OT>
It's in the menus. I don't know where in 7.1, but in 6.0
it's in the 'Project Settings' dialog, "C/C++" tab, category
"Precompiled headers". There are choices to not use, use
'automatic', or use 'manually'.
</OT>

-Mike
Jul 22 '05 #21

P: n/a

"Paul" <pa**@paul.com> wrote in message
news:fxjXc.59716$3O2.48196@trndny07...
"Gary Labowitz" <gl*******@comcast.net> wrote in message >
While I disagree totally with Paul (I figured him for a flamer)
And what exactly do you disagree with? What version of NET? This will not
compile for VC++ 7.1, as noted by several that have that the compiler and
realize that <iostream.h> is no longer included.

The Comeau C++ compiler does the following with the program:
-----------------------------------------------------
Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"iostream.h", line 1: catastrophic error: #error directive:
<iostream.h> is not a Standard header, use <iostream> instead.
Note that when you change this header name, that identifiers

such as
"cout" and "endl" will no longer work, as they are in namespace
"std", so use be "std::cout" and "std::endl" respectively.
------------------------------------------
So again, what is a beginner who may be using a conforming ANSI C++ compiler supposed to do when they get this or similar error message thrown at them
when they compile
their very first program?
From the error message above:

"<iostream.h> is not a Standard header, use <iostream> instead."

That seems pretty straightforward to me, shouldn't confuse even
a novice (unless he's been learning from an incorrect or outdated
book, in which case he *needs* to be informed, the sooner the better).

Reading the "Teach yourself C++" book will not
shed any light
on how to fix this problem.


IMO whatever the name of a C++ book, if it teaches using e.g.
<iostream.h>, *IT IS WRONG* and should not be used.

-Mike
Jul 22 '05 #22

P: n/a
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:j_***************@newsread1.news.pas.earthlin k.net...
<<snip>> "<iostream.h> is not a Standard header, use <iostream> instead."

That seems pretty straightforward to me, shouldn't confuse even
a novice (unless he's been learning from an incorrect or outdated
book, in which case he *needs* to be informed, the sooner the better).

Reading the "Teach yourself C++" book will not
shed any light
on how to fix this problem.


IMO whatever the name of a C++ book, if it teaches using e.g.
<iostream.h>, *IT IS WRONG* and should not be used.


Well, it is not standard. And wth a standard compliant compiler it won't
compile. And that's not useful.
So "wrong" isn't the right word!
What's really on topic here is that a book that teaches non-standard useage
is not useful to today's learner unless they stay with non-compliant
compilers, use extensions like that abysmal MS precompiled header, etc. The
book is outdated. It is difficult to drag people into the 21st century when
quite often the new versions don't work as well, smoothly, or the same way
as the old ones. I shudder to think of all the things I will have to wade
through to move "up" to .NET. (What in hell was wrong with VB 6.0?)
--
Gary
Jul 22 '05 #23

P: n/a
Gary Labowitz wrote:
[...] I shudder to think of all the things I will have to wade
through to move "up" to .NET. (What in hell was wrong with VB 6.0?)


"Everything" doesn't even begin to describe it. The sooner you move
to 7.1, the healthier you're going to be, and the more hair your head
is going to retain.

V
Jul 22 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.