Slashdot Mirror

It's this type of attitude that separates programmers into idiotic "camps". I'm not talking about MS behaving weirdly and making nonsensical decisions -- that's a given. I mean making it sound like C# is oceans apart from modern C++. When you're programming in C++ and STL (along with some Boost, as required), most programs are going to be almost identical in structure. I know this because I've had to port code back and forth from C# to ANSI C++, and apart from some specific, easy-to-isolate areas (like interfacing with the GUI), the structure of the programs remains the same. You should be separating the code that talks with the GUI no matter what language you use, unless your program is heavily intertwined with the GUI (like graphics programs or visualizers).

You should be comfortable using both languages. If you're coming from C# to C++, then check out Accelerated C++, and (some time later) follow that up with this advice.

This isn't like moving from C# to C, it's much closer. Also, you should aim to be a Programmer, rather than a (C++ || Java || C# || Python) Programmer. It'll make your life easier and make you better at your job.

I guess "deprecated" is the wrong term, technically. What I meant was, that "in practice", you'd move past many of the lower-level elements of C++ and use STL instead. There's no reason to write your own String class when there's std::string, nor write your own Array class when there's std::vector (and other containers for array-like structures). Because of this, manual memory allocation is rare -- you'd only use 'new' and 'delete' in very special cases. The rest of the time you'd probably depend on RAII and scoping. You'd also avoid pointers and raw arrays, unless, again, you're *creating* a container, or if there's some extreme performance issue.

Then there's the C-compatibility stuff, that you'd never use in a pure-C++ program. They're just there to stay compatible with C (which is very important, but if you're writing something from scratch, you're not likely to malloc in C++).

These things aren't deprecated, but they are in the "lower level" bracket of C++, and in most situations are there to write the higher-level classes/templates. And since almost any container you're likely to need already exists in the STL, you're not likely to find them in a program that leans on the STL.

That's kind of the philosophy of Accelerated C++, in which the higher-level elements are covered first, and only then does it delve into the lower levels (which is the reverse way of how C++ is learned in academia).
I suppose that the main problem C++ has is its breadth (which I guess is what you meant when you said "complex beast").
(this comment didn't really go anywhere, but I'll post it anyway...)

Urgh, I'm constantly presented with unreconstructed C programs who's code is littered with #defines and arrays, and self written poorly optimised sort functions. Honestly, if you're doing embedded programming C /might/ be the way to go, and it's is a reasonable language to learn about computer architecture with, but it's not a good fit for modern applications. Learn C++, write object orientated code and use the Standard Template Library, do it right and you'll be writing clean/fast maintainable code and developing a skill that's in demand. I'd recommend starting with "Accelerated C++": http://www.acceleratedcpp.com/

DAMN! That's http://www.accelerated cpp.com.

Use Koenig and Moo's Accelerated C++ to teach modern C++ rather than C. Modern C++ (meaning C++ written in a modern style) does not require much memory management or other "nitty-gritty" stuff, but it allows the students to learn in a framework in which such bookkeeping tasks can be introduced with minimal fuss when appropriate. Also, the book is succinct, thorough, and pedantically correct.

I hold the exact opposite opinion.

I believe effective learning should be done in a top-down manner, whereby students start from putting building block together, gradually drill down to understanding how the blocks themselves work. This view is echoed in the classic C++ textbook "Accelerated C++".

Real-world programming requires good exposure to design patterns and programming idioms, and effective use of canned routines. As such, colleges should focus on this skillset in order to equip people for the industry. This is exactly the same reason why nowadays colleges no longer teach hardcore assembly techniques like those used in Knuth. It is absurd that colleges these days still make linked list writing mandatory, and design pattern course an elective.

I myself am a real-time system engineer and back a couple years I taught operating system and computer architecture at Hong Kong Univ of Sci and Tech, I have always been of the opinion that the industry does not need a lot of OS gurus. These hardcore stuff is best be left to the graduated and professionals, who choose to develop in these niche areas.

By far the best book I've ever seen for beginners, or relative beginners, is Accelerated C++. The authors have been involved in C++ since its inception and have been teaching it ever since as well.

If you're interested in Accelerated C++, make sure you get a newer revision -- lots of errata in earlier copies:

See http://www.acceleratedcpp.com/details/errata.html for a listing.

I just ordered this from Amazon.ca... hopefully their copy is newer!

Some problems with this review:

1. Where's the basic information about this book? Author, publisher, ISBN, list price, etc. None of these are mentioned in the review (yes, there's a link to B&N, but, c'mon).

2. Sequencing is an essential aspect of a technical book review. In what order does the author address the topics? Are there many forward references? Does the author march through the topics one at a time or is the subject matter gradually explored, step-wise? A Table of Contents listing (instead of the simplistic 6 parts) would be nice, at a minimum.

Some problems with this book:

1. Having found the TOC on O'Reilly's website (http://www.oreilly.com/catalog/cplus2/toc.html), it's clear that this book features the Bad Old Style of C++ pedagogy: namely, teach C first. The author tackles arrays before std::vector, structs (and unions!) before classes, C-style linked lists before std::list, switch statements before virtual functions, and macros before templates. The new approach to teaching C++ is to give the user familiarity with the powerful utilities of the standard library, so that useful programs can be written right off the bat, and then to explore the dizzying array of language constructs which make the standard library what it is. I encourage those new to C++ to check out Accelerated C++ as an alternative introduction to C++.

2. The reviewer points out that there are many code errors in the book. This is unacceptable, especially for a beginning book. A small number of obvious typos can be forgiven, but anything more than that should consign a tech book -- again, especially an introductory book, where the audience has little experience for dealing with errors -- to the circular file.

While I love many of O'Reilly's offerings, their coverage of C++ has always seemed spotty and outdated. I encourage anyone trying to learn C++ to check out the C++ In Depth series published by Addison-Wesley, starting with Accelerated C++ and Essential C++.

Jon

... is reviewed here, at the 'net's largest C++-oriented book review site. This review is decidedly in the negative, although Steve Oualline is given a chance to issue a response which is worth reading.

It seems that the 2nd edition of this book may have brought forward some previous problems. I have the first edition but never liked it, never thought it really achieved it's goals.

If you're looking for an uncompromisingly amazing first book on C++, please check out Accelerated C++ by Andrew Koenig and Barbara Moo. This is how I learned C++ and, by using the concepts of teaching core language skills alongside library concepts and best practices in OOP, it truly accelerates the process. Amazing.

In the beginners department you can't beat Accelerated C++ by Koenig and Moo. For more advanced programmers there is Scott Meyers.