What to learn?

[Walter Kalata]

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

[Andrew Koenig]

> 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 "Accelerate d
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++.

[jeffc]

"Walter Kalata" <pl****@ucwphil ly.rr.com> wrote in message
news:QZ******** *************@t wister.nyc.rr.c om...

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.

[Martin Eisenberg]

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

[osmium]

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.

[jeffc]

"osmium" <r1********@com cast.net> wrote in message
news:br******** ****@ID-179017.news.uni-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.

[Walter Kalata]

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.

[osmium]

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

[Unforgiven]

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

[Walter Kalata]

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?