What to learn?

Discussion in 'C++' started by Walter Kalata, Dec 15, 2003.

  1. I'd consider myself something of a c++ hobbyist. Rather, I program mainly
    at a personal project level. I started learning when I was about twelve
    years old (currently eighteen), reading various books I could find at the
    local library. In 1999, when I learned about C++96, I realized that it
    really wasn't a great idea to read from someone else's aging book heap. To
    bring this somewhat off-topic post to a point, my c++ book knowledge to date
    consists of:

    Various trash books by filth publishers, i.e. teach yourself c++ in 24
    hours, c++ for the clinically retarded...etc
    Various implimentation-specific books on sockets, windows/mfc programming,
    programming in a posix environment...etc.
    "Extreme Programming In Action"
    Stroustrup's "The C++ Programming Language"
    Scott Meyer's "Effective C++", "More Effective C++", and "Effective STL".
    Josuttis's "The C++ Standard Library"
    Alexandrescu's "Modern C++ Design"

    Recently, I've picked up, but have yet to read:
    Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
    along with the GOF book.

    I'm wondering what good books my shelf lacks, whether anyone can offer any
    advice as to whether to pursue Algorithms or Patterns first, as either topic
    isn't going to be at the top of my agenda and will take a very long time to
    absorb. Any other tips to enrich my programming repetoire will be much
    appreciated.
     
    Walter Kalata, Dec 15, 2003
    #1
    1. Advertising

  2. > I'm wondering what good books my shelf lacks, whether anyone can offer any
    > advice as to whether to pursue Algorithms or Patterns first, as either

    topic
    > isn't going to be at the top of my agenda and will take a very long time

    to
    > absorb.


    At the risk of sounding self-serving, I'd like to recommend "Accelerated
    C++". Although you may find that much of the material in it is familiar, I
    expect that you will probably also find it to be presented in a way that
    offers new insight into how to program in C++.
     
    Andrew Koenig, Dec 15, 2003
    #2
    1. Advertising

  3. Walter Kalata

    jeffc Guest

    "Walter Kalata" <> wrote in message
    news:QZhDb.422546$...
    >
    > Recently, I've picked up, but have yet to read:
    > Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
    > along with the GOF book.
    >
    > I'm wondering what good books my shelf lacks, whether anyone can offer any
    > advice as to whether to pursue Algorithms or Patterns first, as either

    topic
    > isn't going to be at the top of my agenda and will take a very long time

    to
    > absorb. Any other tips to enrich my programming repetoire will be much
    > appreciated.


    Frankly, although the GOF patterns book was the first big one, and probably
    rightly famous, I don't find it all that useful. I think the book is famous
    more because it was a new book on a new topic than because it's easy to
    read. I think there are some newer ones that might be better. Also, I
    haven't read the algorithms book, but if it were me I might find that more
    useful, depending on what I picked up when skimming it.
     
    jeffc, Dec 15, 2003
    #3
  4. Walter Kalata wrote:

    > I'm wondering what good books my shelf lacks, whether anyone can
    > offer any advice as to whether to pursue Algorithms or Patterns
    > first, as either topic isn't going to be at the top of my agenda


    Yes, you want to get something *done*, huh? :) Still, that attitude
    might be a mistake. Besides the fact that many particular algorithms
    in a book like Sedgewick's will come in handy once you got to know
    about them, pondering their properties and why they work the way they
    do -- i.e., Algorithmics -- can help tremendously in thinking about
    your own programs in a clear and focused way. After all, those are
    algorithms, unless they don't terminate ;) It will also lead to
    figuring out some patterns all by yourself, and thus to a deeper
    appreciation of the term "Pattern" (albeit on a different level from
    what GOF talk about). No doubt you'll hit on quite a few things you
    already knew, but only implicitly.

    > Any other tips to enrich my programming repetoire will be much
    > appreciated.


    Looking at your reading list, I guess you're already acquainted with
    the idea of functional programming in addition to the procedural and
    OO mindsets. It is a nice thing to have in one's toolbox.


    Martin
     
    Martin Eisenberg, Dec 15, 2003
    #4
  5. Walter Kalata

    jeffc Guest

    "osmium" <> wrote in message
    news:brkrjm$4dgkp$-berlin.de...
    >
    > But I have a very firm belief that an algorithms book should be language
    > neutral, rather than the language du jour. The latter approach leads to
    > things like _Mathematical Recipes for Fortran_ and the various attempts to
    > make it pertinent in today's world. If the title is garbled, sue me, you
    > know what I mean.
    >
    > Sedgwick has a language neutral version of his book so the advice *can* be
    > followed if one wishes.


    On the other hand, there is also specific language idioms that he would
    probably want to learn.
     
    jeffc, Dec 15, 2003
    #5
  6. Walter Kalata

    osmium Guest

    Walter Kalata writes:

    > Recently, I've picked up, but have yet to read:
    > Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
    > along with the GOF book.


    This advice is too late for you, since you already own the book, and you may
    not like the advice anyway.

    But I have a very firm belief that an algorithms book should be language
    neutral, rather than the language du jour. The latter approach leads to
    things like _Mathematical Recipes for Fortran_ and the various attempts to
    make it pertinent in today's world. If the title is garbled, sue me, you
    know what I mean.

    Sedgwick has a language neutral version of his book so the advice *can* be
    followed if one wishes.
     
    osmium, Dec 15, 2003
    #6

  7. > On the other hand, there is also specific language idioms that he would
    > probably want to learn.
    >
    >


    I was hoping to try to tackle Knuth's series in the future, and correct me
    if I'm wrong, but I doubt that any algorithms I choose (or with the
    libraries of this day and age, need) to impliment from Sedgewick's C++
    Algorithms book would even remotely resemble his sample code, and will be
    built from the textual explaination on how they function, with the code
    sample used more or less as something to double-check with. Couldn't this
    apply to writing the sample code in the language of tomorrow's day?
    Cross-referencing the code with C++ would probably only make it easier to
    understand, especially because at this point C++ is the most natural
    language for me to analyze and fathom, as opposed to pseudo-code, or worse,
    machine code for a pseudo-processor.
     
    Walter Kalata, Dec 16, 2003
    #7
  8. Walter Kalata

    osmium Guest

    Walter Kalata writes:

    > I was hoping to try to tackle Knuth's series in the future, and correct

    me
    > if I'm wrong, but I doubt that any algorithms I choose (or with the
    > libraries of this day and age, need) to impliment from Sedgewick's C++
    > Algorithms book would even remotely resemble his sample code, and will be
    > built from the textual explaination on how they function, with the code
    > sample used more or less as something to double-check with. Couldn't this
    > apply to writing the sample code in the language of tomorrow's day?
    > Cross-referencing the code with C++ would probably only make it easier to
    > understand, especially because at this point C++ is the most natural
    > language for me to analyze and fathom, as opposed to pseudo-code, or

    worse,
    > machine code for a pseudo-processor.


    What I see you saying is that you prefer n%m to n mod m. How do you feel
    about *a++?

    C, and especially C++, are ugly, cryptic, obfuscating languages with some
    plug ugly idioms. C++ is loaded with booby traps, which Sedgewick has to
    provide work arounds for if he did a workman like job. (I don't know if he
    did or not, I have both the C++ version and the language neutral version, I
    always use the latter. BTW I am not particularly fond of either of them, I
    just happen to have them.) As said upstream, no one is proposing you return
    the book you already have. I would lean towards Cormen if I were just
    starting out and had to use a book that is currently in print. Or look
    through used books, I am sure a good source of used books would have
    something *I* would like better than either of these (Cormen, Sedgewick).
    Wirth is at least along the lines of what you want, I assume it is out of
    print. My working hypothesis is that most good books are out of print. My
    post was mostly meant to assist lurkers, not you.

    > or worse, machine code for a pseudo-processor.


    You are going to *love* Knuth :)


    What I see you saying is that m%n makes more sense to you than m mod n. How
    do you feel about *a++?
     
    osmium, Dec 16, 2003
    #8
  9. Walter Kalata

    Unforgiven Guest

    Walter Kalata wrote:
    >> On the other hand, there is also specific language idioms that he
    >> would probably want to learn.

    >
    > I was hoping to try to tackle Knuth's series in the future, and
    > correct me if I'm wrong, but I doubt that any algorithms I choose (or
    > with the libraries of this day and age, need) to impliment from
    > Sedgewick's C++ Algorithms book would even remotely resemble his
    > sample code, and will be built from the textual explaination on how
    > they function, with the code sample used more or less as something to
    > double-check with. Couldn't this apply to writing the sample code in
    > the language of tomorrow's day? Cross-referencing the code with C++
    > would probably only make it easier to understand, especially because
    > at this point C++ is the most natural language for me to analyze and
    > fathom, as opposed to pseudo-code, or worse, machine code for a
    > pseudo-processor.


    At Uni, the Algorithmics and Datastructures courses would use pseudocode.
    Most of the time it would either look a lot like C++ or Pascal, and hide any
    of the uglyness that stuff like pointers adds to an algorithm. If the
    pseudocode is well-chosen, the examples in it can be far more clearer than
    in a relatively low-level language like C++, as the example can focus on
    what the algorithm does, not on how you get C++ to do it.

    Just my opinion of course.

    --
    Unforgiven
     
    Unforgiven, Dec 16, 2003
    #9
  10. osmium writes:
    > What I see you saying is that you prefer n%m to n mod m. How do you feel
    > about *a++?



    Not to start a flame war or anything, but how exactly would you express *a++
    in pseudocode?
     
    Walter Kalata, Dec 17, 2003
    #10
  11. Walter Kalata

    jeffc Guest

    "Walter Kalata" <> wrote in message
    news:fxTDb.218586$...
    > osmium writes:
    > > What I see you saying is that you prefer n%m to n mod m. How do you

    feel
    > > about *a++?

    >
    >
    > Not to start a flame war or anything, but how exactly would you express

    *a++
    > in pseudocode?


    You mean like "Access the value of the thing pointed to by a, and then
    increment a" ?
     
    jeffc, Dec 17, 2003
    #11
  12. Walter Kalata

    osmium Guest

    Walter Kalata writes:

    > > What I see you saying is that you prefer n%m to n mod m. How do you

    feel
    > > about *a++?

    >
    >
    > Not to start a flame war or anything, but how exactly would you express

    *a++
    > in pseudocode?


    I wouldn't. My mind doesn't consider such possibilities when writing
    pseudocode. There are numbers and one can add, subtract, multiply and
    divide them. And there is the notion of a thing called a pointer. These
    are disjoint things.
     
    osmium, Dec 17, 2003
    #12
  13. Walter Kalata

    Jerry Coffin Guest

    In article <QZhDb.422546$>,
    says...

    [ ... ]

    > Recently, I've picked up, but have yet to read:
    > Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
    > along with the GOF book.


    If the purchase was _really_ recent, this may not have been a mistake --
    you might still be able to take these back and get a good book (E.g.
    Knuth or Cormen, Rivest et. al.) instead. Otherwise, about the best way
    to use these to learn about algorithms is to burn them to give yourself
    light to read a different book.

    > I'm wondering what good books my shelf lacks, whether anyone can offer any
    > advice as to whether to pursue Algorithms or Patterns first, as either topic
    > isn't going to be at the top of my agenda and will take a very long time to
    > absorb. Any other tips to enrich my programming repetoire will be much
    > appreciated.


    IMO, a book on algorithms should come before one on patterns. Patterns
    occur in the implementation of algorithms. Until you know what
    algorithm you're going to implement, the patterns involved in their
    implementation are more or less irrelevant.

    Once you have at least one decent book on algorithms, it's probably time
    to start thinking more in terms of what interests you and what kinds of
    programs you really want to write -- depending on your interests, that
    might be a book on compiler writing, or numeric analysis, or number
    theory, or any number of other possibilities.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Dec 18, 2003
    #13
  14. Walter Kalata

    Jerry Coffin Guest

    In article <QZhDb.422546$>,
    says...

    [ ... ]

    > Recently, I've picked up, but have yet to read:
    > Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
    > along with the GOF book.


    IMO, the Sedgewick books are best replaced with something else -- I like
    Knuth, but Cormen, Rivest, et al, is quite good as well. The Sedgewick
    books, however, are basically worse than nothing at all. For the
    theorist, their analysis is so shallow as to be meaningless at best, and
    more often downright misleading, so you'll need to unlearn what they
    teach before you can learn anything else.

    For the pragmatist who wants to implement the algorithms, they're even
    worse. You often turn to a book to clarify details on algorithms you
    already _basically_ understand. These books contain such lousy
    explanations, that after reading them, you'll no longer just be confused
    over the details, but probably be confused over the basic idea of the
    algorithm too. In case the poor explanations don't confuse you, he
    still has an ace up his sleeve: sometimes he'll claim to describe one
    algorithm, but really describe something almost completely different.

    I've had a copy of the GoF book since it first came out, and while I can
    understand some of the enthusiasm about it, I have to say that I've
    never found it particularly useful either. OTOH, it's not anywhere
    close to the same class as Sedgewick -- even at very worst, it's utterly
    harmless, which is a lot better than can be said for Sedgewick.

    > I'm wondering what good books my shelf lacks, whether anyone can offer any
    > advice as to whether to pursue Algorithms or Patterns first, as either topic
    > isn't going to be at the top of my agenda and will take a very long time to
    > absorb. Any other tips to enrich my programming repetoire will be much
    > appreciated.


    IMO, algorithms first, patterns later. Knowing algorithms is what
    allows you to accomplish something. Knowing patterns allows you to
    write nicer code to accomplish it. Knowing patterns without algorithms
    allows you to write nice code that doesn't accomplish anything.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Dec 18, 2003
    #14
    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. -XC-
    Replies:
    4
    Views:
    722
    barkerl
    May 23, 2005
  2. Mike
    Replies:
    1
    Views:
    2,158
  3. Porky Pig Jr
    Replies:
    3
    Views:
    1,058
    Fuzzyman
    May 12, 2004
  4. CoreyWhite
    Replies:
    1
    Views:
    660
    JohnQ
    Mar 31, 2007
  5. Alexander
    Replies:
    20
    Views:
    1,058
    BGB / cr88192
    Sep 11, 2010
Loading...

Share This Page