If you're new and need a book

Discussion in 'C++' started by Carter Smith, Aug 24, 2004.

  1. Carter Smith

    Carter Smith Guest

    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
     
    Carter Smith, Aug 24, 2004
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Aug 24, 2004
    #2
    1. Advertising

  3. Carter Smith

    Default User Guest

    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
     
    Default User, Aug 24, 2004
    #3
  4. Carter Smith

    Carter Smith Guest

    language books don't get outdated

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

    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.
    There may be a new algebraic theorum that was recently proven.
    http://www.cut-the-knot.org/pythagoras/index.shtml

    The statement of the Theorem was discovered on a Babylonian tablet circa
    1900-1600 B.C. Whether Pythagoras (c.560-c.480 B.C.) or someone else from
    his School was the first to discover its proof can't be claimed with any
    degree of credibility. Euclid's (c 300 B.C.) Elements furnish the first and,
    later, the standard reference in Geometry. Jim Morey's applet follows the
    Proposition I.47 (First Book, Proposition 47), mine VI.31. The Theorem is
    reversible which means that a triangle whose sides satisfy a2+b2=c2 is right
    angled. Euclid was the first (I.48) to mention and prove this fact.

    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? You
    can't get much more outdated than 2000 years and yet here we are still
    teaching it and relying on it.

    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.

    There's a reason a computer science degree includes classes in "outdated"
    things such as 186 assembly and digital logic that doesn't get past a simple
    4-bit computer with only a handful of bytes of memory.

    If you know of some specific books that you think would be a good addition
    to the library that are legal to redistribute then let me know. If you have
    a specific book in mind that has a newer edition available then let me know
    where to get the newest edition. Don't just blindly accuse me of posting
    "outdated" materials. How long have the red and blue OpenGL books been
    around and they're still the defacto standards?

    Ben Kucenski
    www.icarusindie.com



    "Victor Bazarov" <> wrote in message
    news:SnHWc.218$09.us.to.verio.net...
    > 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
     
    Carter Smith, Aug 25, 2004
    #4
  5. Carter Smith

    Paul Guest

    Re: language books don't get outdated

    "Carter Smith" <> 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
     
    Paul, Aug 25, 2004
    #5
  6. Re: language books don't get outdated

    "Paul" <> wrote in message news:Ts_Wc.6572$rT1.2406@trndny02...
    >
    > "Carter Smith" <> 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
     
    Gary Labowitz, Aug 25, 2004
    #6
  7. Carter Smith

    Jerry Coffin Guest

    Re: language books don't get outdated

    "Carter Smith" <> 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.
     
    Jerry Coffin, Aug 25, 2004
    #7
  8. Carter Smith

    Carter Smith Guest

    That's all syntax

    > 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
     
    Carter Smith, Aug 25, 2004
    #8
  9. Carter Smith

    Carter Smith Guest

    Re: language books don't get outdated

    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" <> wrote in message
    news:...
    > "Paul" <> wrote in message

    news:Ts_Wc.6572$rT1.2406@trndny02...
    > >
    > > "Carter Smith" <> 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
    >
    >
     
    Carter Smith, Aug 25, 2004
    #9
  10. Re: language books don't get outdated

    [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?
     
    Alf P. Steinbach, Aug 25, 2004
    #10
  11. Carter Smith

    red floyd Guest

    Re: That's all syntax

    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.
     
    red floyd, Aug 25, 2004
    #11
  12. Carter Smith

    Default User Guest

    Re: language books don't get outdated

    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
     
    Default User, Aug 25, 2004
    #12
  13. Re: language books don't get outdated

    "Carter Smith" <> 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.
     
    Niklas Borson, Aug 25, 2004
    #13
  14. Carter Smith

    Jerry Coffin Guest

    Re: That's all syntax

    "Carter Smith" <> 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.
     
    Jerry Coffin, Aug 26, 2004
    #14
  15. Carter Smith

    Paul Guest

    Re: language books don't get outdated

    "Carter Smith" <> 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?
     
    Paul, Aug 26, 2004
    #15
  16. Carter Smith

    Paul Guest

    Re: language books don't get outdated

    "Gary Labowitz" <> 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.
     
    Paul, Aug 26, 2004
    #16
  17. Re: language books don't get outdated

    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.
     
    Steven T. Hatton, Aug 26, 2004
    #17
  18. Carter Smith

    Ron Natalie Guest

    Re: That's all syntax

    "Carter Smith" <> 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.
     
    Ron Natalie, Aug 26, 2004
    #18
  19. Re: language books don't get outdated

    "Paul" <> wrote in message
    news:fxjXc.59716$3O2.48196@trndny07...
    > "Gary Labowitz" <> 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
     
    Gary Labowitz, Aug 26, 2004
    #19
  20. Re: language books don't get outdated

    "Paul" <> wrote in message news:GcjXc.16994$oD2.105@trndny08...
    >
    > "Carter Smith" <> 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
     
    Gary Labowitz, Aug 26, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doris Cox
    Replies:
    0
    Views:
    550
    Doris Cox
    Dec 2, 2003
  2. Dennis
    Replies:
    0
    Views:
    696
    Dennis
    Dec 2, 2003
  3. pek
    Replies:
    0
    Views:
    1,225
  4. Xah Lee
    Replies:
    0
    Views:
    528
    Xah Lee
    Jul 31, 2010
  5. johannes falcone
    Replies:
    6
    Views:
    1,002
    johannes falcone
    May 16, 2013
Loading...

Share This Page