5

Possible Duplicate:
C++ tutorial for experienced C programmer.

I program in a number of languages frequently and have been using C++ lately. Basically my classes are just wrappers around pure C code. Almost like a struct with associated methods. This gives me the encapsulation and privacy that I want for my data. I have a small hierarchy of classes and am just barely using inheritance.

I am familiar with OO concepts and know what search terms to use when i need to find out about a particular concept in this regard. However, as I have discovered in my foray in the programming world, often the language features that are really helpful are hidden to the newcomer or novice, and the useful bits that I need have already been written and are in a library somewhere that is freely available (most times part of the framework - like in .NET).

What path would you suggest to gain this vital knowledge in C++ and stop myself reinventing the wheel (poorly).

Community
  • 1
  • 1
Aran Mulholland
  • 23,555
  • 29
  • 141
  • 228
  • 1
    I use to do exactly this, I still do to an extent, except for I don't use C++ much anymore. – Earlz Jan 24 '11 at 02:07
  • 3
    http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list – Mitch Wheat Jan 24 '11 at 02:09
  • 1
    Oh goodie, my biggest pet peeve. Pretend you don't know *anything*, now how would you learn C++? (With a book.) That's how you go about it. If you happen to think you know something already, just mark it off as a coincidence. You don't transition, you learn anew. – GManNickG Jan 24 '11 at 03:03
  • @GMan, But don't I already know a third? Ive got the "C" all i need is the "++" :) – Aran Mulholland Jan 25 '11 at 02:51
  • @Aran: Cute, but no. Language isn't just syntax. – GManNickG Jan 25 '11 at 07:48
  • 1
    See: [C++ tutorial for experienced C programmer.](http://stackoverflow.com/questions/1421668/c-tutorial-for-experienced-c-programmer). See also: [C: Good Habits re: Transitioning to C++](http://stackoverflow.com/questions/1420685/c-good-habits-re-transitioning-to-c) and especially the list of books that Mitch links to. – Shog9 Jan 25 '11 at 18:16

9 Answers9

9

This is the wrong way to use C++. You would be better served grabbing a copy of Accelerated C++ and reading it. Yes, it's a beginner book but unless you want to continue treating C++ as just C with objects then you need to focus on how C++ programmers do things instead of just sticking with what you already know. You need to start from the beginning and build a good foundation in C++.

Edward Strange
  • 40,307
  • 7
  • 73
  • 125
  • I disagree. When you go to write, say a quicksort algorithm or something, almost all of the code would be the same between C and proper C++. You don't need to learn how to program from scratch, just how to take full advantage of the added features of C++. – Earlz Jan 24 '11 at 02:14
  • 7
    Not when _I_ write a quicksort algorithm. My C++ implementation would look very much different from my C version. You've actually pointed out a great example why those who continue thinking of them as the same language are destined to fail. – Edward Strange Jan 24 '11 at 02:17
  • 4
    @Noah: a good C programmer can write better programs by introducing a little C++ (as Aran's evidently done). That's not destined for failure. It also doesn't mean he's getting the full benefit, and it certainly doesn't mean he's ready to work in a team with other C++ programmers or on C++ code that uses the full features. But, there's nothing inherently wrong with it either, and as an evolutionary stage in the developer experience, it's not to be condemned or mocked as "the wrong way to use C++". It's a humble beginning to be encouraged. Deep end of the pool treatment isn't the only way. – Tony Delroy Jan 24 '11 at 02:59
  • 2
    @Tony - Accelerated C++ is pretty far from any "deep end". People do themselves a disservice treating C++ as you suggest. You don't learn a new language effectively by treating it as a different one. Just like I wouldn't hope to jump into C# by treating it like C++, nobody should consider jumping into C++ by treating it like C. Accelerated C++ teaches a solid foundation in treating C++ like C++. It's a very easy to read book, at the beginner level, and an experienced developer should have no problem catching up quite quickly by using it. I didn't recommend the TMP book. – Edward Strange Jan 24 '11 at 03:03
  • 4
    @Tony: C is a simple language. To learn it, you learn the pritimve types, statements, etc...then you *piece things together*. C++ *doesn't work like that.* In C++, we work with black boxes that satisfy certain criteria and perform a task. You should learn to use a `std::vector` before you learn about `new[]`, because the box is more useful, safe, and pragmatic then `new[]`. That doesn't mean you should never learn `new[]`, but it's certainly not needed during the process of learning; it comes at the end, in fact. So this approach of "C, C with classes, C with templates, etc..." is backwards. – GManNickG Jan 24 '11 at 03:09
  • @Noah: I've no disagreement re Accelerated C++, just the general attitude and that statement "wrong way". In a perfect world where you have time to learn what you want to, what you suggest is fine. If, say, you have a project to do and can use it as a chance to start learning some C++ concurrently, but can't take time out just for that, then edging in as Aran describes is reasonable. – Tony Delroy Jan 24 '11 at 03:27
  • @GMan: I do recommend to C programmers that they learn C++ by first adopting the STL containers: that's the easy drop-in win for them. C with classes starts providing abstraction and localisation: that's a big but intrusive win for better organised, maintainable, localised, encapsulated code. It's still useful even without runtime polymorphism. templates would be one of the last things I'd specifically target, although the basic mechanism will be familiar to advanced C programmers who've used preprocessor macros for similar purposes. – Tony Delroy Jan 24 '11 at 03:33
  • @Tony - you seem to be suggesting that it is reasonable to use an important, time constrained, project as a learning ground. I would suggest that this is an even worse idea than treating C++ like C with some added stuff. I might even go so far as suggest that at the very least you need one team member with nothing short of advanced knowledge of the language you intend that product to be written in and preferably more than one. You seem to be suggesting that a reason to treat C++ like C is you don't have the time to do it right. Seems to me that implies some already questionable decisions. – Edward Strange Jan 24 '11 at 04:19
  • 3
    @Noah: yes, I am suggesting that: in constantly busy, understaffed teams, programmers do have to teach themselves on the job by adopting bits of promising new technology when they can. Otherwise, they stagnate. Management pay programmers who make questionable development scenarios work, moving things in the right direction even if it's incremental: in fact, they may prefer something incremental over the risk of pulling in some untried external "expert" who wants to rewrite everything immediately in a new language. C++ is a near-superset of C: it can be smart to leverage that at times. – Tony Delroy Jan 24 '11 at 04:28
  • 1
    @Earlz One almost never writes a quick sort (or other such common algorithm): one uses a library. The bulk of code you are writing should be focused on the overall domain of the problem and here OO (especially composition) becomes really valuable. – Richard Jan 24 '11 at 08:23
  • @Tony - I of course never suggested hiring a new programmer that "wants to rewrite everything immediately". You're taking everything I say and creating absurdity from it where there was none. What I actually said was that once the decision to write a product in a language was made, you should have someone available that knows it. Nothing absurd about that and no, it is not suggesting what you are claiming. Of course I don't expect you to agree with this as nothing you've said so far seems reasonable to me. The least one can expect though is HONEST rebuttal. – Edward Strange Jan 24 '11 at 17:26
  • @GMan a very good point. @Richard and @Noah. Maybe I was thinking about it a bit wrong. I should've said Algorithms never change. A beginning programming book can be different from a beginning C++ book. – Earlz Jan 24 '11 at 23:22
4

Learn the STL if you're going to really plan to use C++ in the future. Though opinions will vary widely, particularly among the die-hards, I think there is absolutely no problem using C++ as "C with objects."

Boost is also pretty awesome.

EDIT: Note the downvotes already coming in from the die-hards. C++ acolytes really don't like to hear people advocate using the language as "C with objects." I stand by my statement. You can write quite shippable and commercially viable code without going crazy with an RTTI-enabled, templatized, multiply-inherited set of classes. Remember KISS.

par
  • 17,361
  • 4
  • 65
  • 80
  • +1 to counter downvote. There is no point to downvote just because you disagree with the answer... – Jesse Emond Jan 24 '11 at 02:24
  • 1
    @Jesse - actually, that's exactly WHY you should downvote an answer, when you think it's in error and unhelpful. This answer is misleading and erroneous. With the edit in place it's half tempting to flag it as inappropriate. – Edward Strange Jan 24 '11 at 02:27
  • 3
    @par: You can ship perfectly viable commercial code from COBOL in 2011 too, doesn't mean you should. Saying 'it can work anyway' is not a good reason to persist in not taking advantage of a laguages features. Keep in mind, we're not talking about "Should I stick with my company's coding guidelines that forbid RTTI?"... we're talking about "How should I expand my knowledge of programming techniques?", the answer isn't "Pretend all those features don't exist", and that's why you're getting downvoted. – jkerian Jan 24 '11 at 02:29
  • Thanks Jesse, although I do agree with Noah that a downvote should be used if you think an answer is misleading or erroneous. In this case though I have shipped software that has made both millions of dollars and has been adopted by millions of people using only basic features of C++ layered on mostly C. It enabled us to write clean, understandable code that has held up maintenance-wise for years. If that is misleading or erroneous I'm happy to have it so. – par Jan 24 '11 at 02:31
  • @jkerian - I know folks who are still in 2011 using COBOL. In some environments it is still the right tool for the job. – par Jan 24 '11 at 02:33
  • 9
    ++ Yay for pragmatism! Outside of MFC and some libraries, I've never seen a system put together by true C++ believers that wasn't massively overblown. Hundreds if not thousands of classes, wrappers upon wrappers, notifications galore, every acronym in the book, much pontificating on private this and polymorphic that, virtual destructors, inheritance, blah, blah, everything *but* the problem we're working on. – Mike Dunlavey Jan 24 '11 at 02:35
  • 5
    @par - recommending that learning the STL is somehow optional to becoming a good C++ developer is more than just misleading. Attacking opposing POV by calling anyone who disagrees "die-hard" is also misleading, inappropriate, and uncalled for. If you can't make your point without such FUD then you really don't have any point worth making. Yes, you CAN simply ignore the rest of C++ and just use the C library with objects but the OP is specifically asking how to learn MORE. Disagreement about what one should do aside, your answer makes for a very poor and unhelpful reply. – Edward Strange Jan 24 '11 at 02:37
  • 1
    @Mike: The fact that you use MFC as an example of a non-overblown library is... confusing. Among C++ devotees... I think MFC is generally held up as the prime example of how to create an overly complex mess. – jkerian Jan 24 '11 at 02:38
  • @jkerian: On a logarithmic scale, I'd put MFC around the middle. I've seen some 3rd-party controls for grids and plotting that dwarf MFC. Their defenders might say that's because they're chock full of features, but permit me to doubt. – Mike Dunlavey Jan 24 '11 at 02:41
  • 3
    @jkerian - one of the main problems with MFC is that it is too much C. To be fair, it's extremely old and was never meant to serve as anything more than a very thin wrapper over a very confused C API. Not only is MFC very poor C++, the API it wraps is, in my opinion and experience, very poor C. So basically in MFC you have a compounded clusterfsck of the worse use of everything. It's the worst of C wrapped up (barely) with the worse of C++. – Edward Strange Jan 24 '11 at 02:43
  • 2
    @Dunlavey - if you're really using C++ without virtual destructors, and think that worrying about virtual destructors is superfluous pontificating then you really have no business writing C++ code. Virtual destructors are absolutely essential knowledge even if you're only using C++ as C with objects. Lack of knowledge about them and lack of use will inevitably lead to very poor and incorrect code (and incorrect is measured in the purest sense: the program doesn't work correctly). You really couldn't have done your 'side' a worse argument. – Edward Strange Jan 24 '11 at 02:46
  • 2
    @Noah - I consider myself a C++ die-hard and I'm certainly not advocating that he ignore the advanced language features and programming techniques that C++ enables. I'm suggesting merely that what he is currently doing is a perfectly reasonable means of developing software as he learns more. If I had to choose (and in my job I do) between someone who knows every nuance of the language and someone who writes clean, reliable, and understandable code I choose the latter every time. – par Jan 24 '11 at 02:47
  • 1
    @par - In my experience, those lacking sufficient knowledge of the language (not knowing the STL for example) are incapable of writing clean, reliable, and understandable code. For one thing, like it or not, knowledge of language nuance is extremely important for writing reliable software. Lack of understanding regarding exception safety for example. Of course, you can just run away and pretend exceptions don't exist but then that tosses out a very useful and important tool that enables you to write clean and reliable software (and doesn't save you from their effects anyway). – Edward Strange Jan 24 '11 at 02:54
  • @Noah: there are lots of valid uses of objects that don't require run-time polymorphism, hence don't need virtual destructors. Some problem domains do lend themselves to full OO modelling more than others - if working in such a domain, you'd want to start exploring virtual dispatch earlier, but it's not an essential thing to start using C++. – Tony Delroy Jan 24 '11 at 03:02
  • 1
    I find myself *strongly* agreeing with Noah Roberts here, and that hardly *ever* happens. It's one thing to point out that you can write commercially or otherwise viable code without doing things the "right" way. It's done all the time, and sometimes it even makes business sense. It's also 100% accurate that most beginners to a language don't bother to learn its complexities and best practices, but only the bare essentials they need to get started. But neither of those things make it worth *encouraging* people to do this. – Cody Gray - on strike Jan 24 '11 at 04:42
  • @Noah: When I was an AI-monster, I was full of the "party line" and had ready answers for why what other people were doing was all wrong. Now the crusade I'm on is to have as little data structure as possible. I have no doubt you're right that it's useful and important to understand all those points. Where I've arrived is I'm witnessing things getting built that, relatively speaking, make MFC look like poetry. Somehow I manage to make pretty good apps in C++ and C#, with lots of features, but 1 or 2 powers of 10 less code than what I see. – Mike Dunlavey Jan 24 '11 at 14:18
3

Scott Meyers' books are a great place for C programer to begin with C++.

ThomasMcLeod
  • 7,603
  • 4
  • 42
  • 80
  • 3
    Not really. I actually went that route, or tried to, many years ago when learning C++. Meyers' books are good for someone that's already got the basics in C++ down and is ready to learn some good rules of thumb. There's a whole bunch of stuff a C developers needs to know before hand. Certainly none of Meyers' books could make an ONLY book for starting out. – Edward Strange Jan 24 '11 at 02:22
  • @Noah: fair enough, but OP was looking for "useful bits." – ThomasMcLeod Jan 24 '11 at 02:30
  • I don't know that the Meyers books are the first ones to start with but they're absolutely mandatory reading and probably come second. Even starting out you can't go wrong reading these, just plan a reread once you've got more experience. – par Jan 24 '11 at 03:23
  • Might want to name them: _Effective C++_, _More Effective C++_, _Effective STL_. Oh and +1 for being right. These are hands down the BEST books for understanding the how and why of c++. – KitsuneYMG Jan 24 '11 at 06:03
2

I recommend Thinking In C++ by Bruce Eckle. Normally it's available for free online, or as a book.

Aran Mulholland
  • 23,555
  • 29
  • 141
  • 228
crimson_penguin
  • 2,728
  • 1
  • 17
  • 24
2

I suggest you read the books:

"C++ Coding Standards: 101 Rules, Guidelines and Best Practices" --Sutter & Alexandrescu

"Modern C++ Design: Generic Programming and Design Patterns Applied" --Alexandrescu

And probably anything else by Andrei Alexandrescu that you can get your hands on.

Then, there are a number of design patterns and programming idioms that make it very clear why "C with objects" is extremely reductionist. Just to name a few: RAII (Resource Allocation Is Initialization), PImpl (or Cheshire Cat), Factory functions, Smart Pointers, Singleton, Type Traits, Expression Templates, etc. When you know about these, you are no longer programming in C++, but in ++C (because you get a result that actually reflects the increment over C).

As for not reinventing the wheel, like many have said already, make sure to first explore the possibilities in the Standard Template Library (STL) (which is much richer than you might think) and then look at Boost (www.boost.org) which has libraries for a lot of diverse purposes and they are extremely high quality (and some are just works of art, like Spirit, Proto, Lambda and MPL). After that, there is of course a large amount of open-source software in C++ out there, but use it with caution: sometimes it is better to reinvent a wheel that fits perfectly to your application than to use one that might not be appropriate or powerful enough, or worse, full of bugs!

Mikael Persson
  • 18,174
  • 6
  • 36
  • 52
  • 1
    The Coding Standards book is pushing it. Remember that the OP only knows C at this point. C++ use has been limited to adding member functions to structs. The Coding Standards book assumes quite a bit more knowledge than that. It might be a good supliment but like Meyers, couldn't be a sole starter. Alexandrescu's book is considerably more advanced material. It can be easy to forget just how advanced some of these materials are when you're no longer a beginner. Modern C++ Design isn't going to help a newbie at all. – Edward Strange Jan 24 '11 at 04:26
1

I suggest the book The C++ Programming Language for filling in the gaps in your basic C++ knowledge, and BOOST as the first place to look for existing libraries supporting your programming.

Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
0

Have you thought about getting the C++ Primer Plus? It's a really good book.

David Weiser
  • 5,190
  • 4
  • 28
  • 35
  • 1
    I hated that book. No downvote because you're not wrong per se: But I found it to be long-winded and full of useless, generic programming crap. You know, like most books on programing that expect you to have trouble with not wetting the bed. – KitsuneYMG Jan 24 '11 at 06:05
  • Actually, that's a more known *bad* book. :X – GManNickG Jan 24 '11 at 19:02
0

The C++ Standard Library: A Tutorial and Reference

Jared Farrish
  • 48,585
  • 17
  • 95
  • 104
0

Read Meyers for specific tips, but also Stroustrup's Design and Evolution. The latter gets into the motivation as to why C++ is what it is, and very much comes from a "how to improve C" viewpoint. As for "The C++ Programming Language", 3rd edition is very long. If you can find the 2nd edition, its much more digestible, although of course occasionally out of date (but mostly just less complete).

Keith
  • 6,756
  • 19
  • 23