January 2, 2008

C++ Bleg

Posted by Arcane Gazebo at January 2, 2008 9:08 PM

I learned C back in high school but never got around to C++, since it was never something I needed for my physics studies. However, many of the jobs I've been applying for list C++ proficiency as strongly preferred (if not required), so now seems like a good time to learn something about it. Can anyone recommend a book on the subject? Or is reading a book the wrong way to approach the problem? I should note that as an undergrad I was familiar with C and had done a bit of object-oriented programming in Java, but I haven't used either very much since.

Tags: Technology
Comments

Reading is usually the wrong way to go about this. At least for software industry jobs, just reading a book on the subject won't give you the experience necessary for interview questions. That said, the right way is usually to use it in something you're working on, and having a good book for reference is very handy. Depending on the type of job, I'd try to work on a project involving OO programming (with polymorphic objects) and/or templates, that would get you experience with debugging that type of code and how to use the various pieces.

That said, I don't have a decent reference book handy but I'll check if there's anything I'd recommend. As far as projects go, there's probably a lot you could work on, most any type of problem can be approached with these tools.

Posted by: Zifnab | January 2, 2008 11:02 PM

Dietel and Dietel (no clue on spelling had a good book.

That said you may want to find a 1 high intestiy week course. something liek what developmentor offers. They use to offer c++ for c programers

Posted by: shellock | January 3, 2008 6:08 AM

I'm not sure about books for learning C++, but once you think that you basically understand the language, I recommend getting the following:

Effective C++ and More Effective C++ by Scott Meyers. Every C++ programmer should read these. They cover many edge cases, warts, things that you can but shouldn't do, and the few cases in which you would want to do them. They're also great books to refresh your memory if you've not used the language for a few years - most aspects of the language's grammar are covered one way or another.

The O'Riley C++ pocket guide, which is wonderfully useful for when you forget some piece of syntax, and C++ has a lot to forget. I keep this on my desk at arm's reach, and typically need to look up some point of minutiae weekly. (How to I specify a pointer to a constant pointer to non-constant data?)

I'd also recommend Effective STL by Scott Meyers if you've learned the C++ STL. I'm not sure if the STL is widely used, though.

I'd like to give a warning that C++ is is one the the 'trial by fire' languages of computer programming. It's a powerful and potentially flexible language, but it leaves a lot of work to the programmer. The programmer is expected to explicitly state where to trade speed for flexibility, and there are many, many ways to shoot yourself in the foot.

Finally, I would like to note that, while its features are bountiful to the point of being counter-productive, C++ lacks many excellent object-oriented features. It's a great language to have on your resume, it's very useful for limiting how much time and space a piece of code will use, and it's great for teaching oo code optimizations, but, much like C, it sucks for flexibility, getting things done fast, and learning more advanced programming techniques.

Posted by: Nick | January 3, 2008 11:09 AM

Hoo boy, now there's a real Pandora's Box you've just opened up.

As far as reading, I agree with Z -- you will be served best by doing, and supporting it with reading. There are a handful of books that are absurdly more relevant than the rest, however.

1: The C++ Programming Language, by Stroustrup. As far as what the language is, as well as why, that's your source. It's big, and sometimes slow, however.

2: The C++ FAQ, or the FAQ-lite (available for free online) will answer many of your questions as you start out. The lite version is short enough (and useful enough!) to also warrant a straight read-through once you're starting to feel comfortable with the basics.

3: Effective C++, 50 Specific Ways to blah blah blah... is a great book for good programming practices in C++, but that's your expansion pack once you've reached some basic competency.

You can take different approaches to programming, even in the same language. One way I hear it said is that "You can write FORTRAN in any language". (As in write fortran-styled code, not implement the language)

OO is a different approach, a different style to programming. Templates are another approach again, that partially build on OO, but partially take another angle of attack on a similar problem (polymorphism and code reuse).

A few tips, then:

C++ is a very permissive language, in terms of how you're allowed to approach the problem. This will sometimes make the "ideal" approach more elusive. Also, you will inevitably (and repeatedly!) ask yourself, "why is the language making this so difficult?" Nine times out of ten (but only nine!), that means a slightly different approach would serve you better. C++ is, pretty much, every bit as permissive as possible while still maintaining consistency and well-defined-ness. This usually means that, if you think the language is getting in your way, chances are what you're trying to do has implications that you're not appreciating (or at least how you're trying to do it). The C++ FAQ is usually a quick fix to confusions along these lines -- everyone comes across them.

A common trap is to think that using cout instead of printf makes your code C++. Really, it just makes your code C that needs a C++ compiler. Sometimes in good C++ you still prefer printf, but streams (cout) give you a nice, language-supported alternative that plays nice with new, user-created datatypes. First, learn the OO paradigm. A question I always ask people is, "What is the difference between a class and an object?" (Python programmers STFU okay?).

Learn about the STL and iterators! At times the STL can be a bit obtuse, but it's very featureful and reliable. It is really part of the language, in that if you have a C++ compiler, you also have the STL available. Period. With the STL, a lot of simple data structures you may be tempted to write can be implemented in one typedef line.

Okay, I want to type more, but keep getting distracted. I really need to focus on work. I have really strong opinions on this, btw (I won't say good or bad, just strong).

I do write about 90% of my code (and that's a lot!) for work in C++. I write OO with a lot of templates, both STL and custom. I've implemented a few of the template metaprogramming classics (like template expressions), but think that often they're more trouble than they're worth -- just because you can write something in templates doesn't mean you should. There are only a few of the big "design patterns" that I find useful, though I think more would be in a different context.

Posted by: Lemming | January 3, 2008 11:28 AM

Nick:

I didn't check again for new posts before I posted after I finished writing. Yeah, More Effective C++ is also an important one, though not as much marginal gain after reading the first. I use the O'Reilly C++ In a Nutshell for quick-quick stuff. Not as small, but contains a good STL reference. STL use is a big deal -- you don't necessarily need all of it, but a lot of common, simple and grungy tasks get much easier if you're willing to use it.

I also second the "trial by fire" comment.

What sort of OO features are you referring to that C++ is missing? If you just drop a few terms, I can look them up on my own if I don't know them. I've only written OO code in a few language, and I've never found C++ lacking in those sorts of features, but that is very possibly my own ignorance.

Posted by: Lemming | January 3, 2008 11:39 AM

As an aside, I don't mean to defend/preach C++. It's a useful language, but it does have its problems. For my job, it's the best single language (a hybrid of other languages would be a possible alternative).

A common thing I hear about at companies I respect is to use one of a small number of languages based on the task -- C++, Python and Java coming up frequently, all of which I like. I think C# might be a better language than Java (though inferior for reasons of deployment), but I've only dabbled in it so far.

Posted by: Lemming | January 3, 2008 12:00 PM
Post a comment