Hacker News Reader

Comment by andrewcooke | Hacker News Reader

so is there a good book that shows how to write c++ code correctly, so that it's as "clean and safe as code written other modern languages"?

for example, it would probably avoid introducing pointers until very late, using standard containers for data structures, etc.

the approach would be more "here is a modern language using the right subset of c++" rather than "you can make clunky old c++ work by following these arcane rules to avoid weird exceptions" (ie it shows a complete, modern language, not a collection of work-arounds). and preferably it should be aimed at an experienced programmer, so it should be compact and not try teach me "how to program" in general.

View on HN

I think that "Accelerated C++ Programming by Example" [1] is a good introduction to modern C++. It focuses on the correct use of the standard template library which I think is at the heart of much of modern C++.

Needless to say, C++ is very complex and so the book doesn't cover a good part of it. But I think it is a fairly good start and is not too long either.

[1] http://www.acceleratedcpp.com/

thanks, but although they look like good authors, and it's promisingly slim, it's also worryingly old. is there nothing more modern? will it include things like boost's shared_ptr (see comment above)?

I think Effective C++ by Scott Meyers[1] is the gold standard when it comes to books on writing good clean C++. It assumes that you already know the basic syntax though and already know how to program. This allow him to skip the intro stuff that take up the most space in many books and get strait to telling you what you need to know to write better code.

[1] http://www.amazon.com/Effective-Specific-Improve-Programs-De... (Make sure you get the latest edition, a lot has changed for the better)

Meyers book has been the book I'd recommend to anybody moving beyond the beginner stage in C++, but there's so much critical stuff in the new standard that the last edition of his book doesn't cover that I'd hesitate to recommend it now. I think you're better off studying some of the resources available online, like the videos at http://channel9.msdn.com/

That is, of course, only until a new edition of Meyers' book comes out.

This is a good intro to modern C++ from Herb Sutter: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T It's from MS's Build conference but not specific to any platform or tools. I really enjoyed the video though, especially when he compares an old C-style program to a modern C++ version--very much an aha! moment for me that C++ has evolved into a really nice language.

> probably avoid introducing pointers until very late

Introduce shared_ptr<> early, explain how actual pointers should pretty much only be used for compatibility with old-style libraries or if you're the one writing the standard library.

I would say that using a shared_ptr is going the wrong way. A shared_ptr is a reference counter pointer and as such as many shortcomings, such as not being able to do cyclic data structures, being slow, hard to make thread safe. They're also quite complicated and require knowledge of C++ destructors, copycons, RAII, etc to understand.

So, please, don't push shared_ptr as a magic one-size-fits all solution, especially to newbies. There's a reason why reference counting is not used everywhere.

With C++ you must remember that it's using pass-by-value semantics by default, which is very different from pass-by-reference semantics of other (syntactically similar) languages (like Java). Using shared_ptr's will not get rid of this fact and makes things even more complicated.

In fact, I have a very hard time to find _any_ use for shared_ptr's in my C++ projects. scoped_ptr's and ptr_containers have proven to be more useful.

Actually since most if not all CPUs have an atomic increment instruction it is quite easy to make shared_ptr<> thread-safe. In fact, that is what boost::shared_ptr<> does. This makes it a good tool for resources that may be shared between threads or for cases where it's just not worth the mental overhead of worrying about ownership.

That said, shared_ptr isn't a solution to everything. Sometimes scoped_ptr (called unique_ptr in tr1) or intrusive_ptr is a better tool. Often if you don't want to share or transfer ownership, passing around a raw ptr or reference is even better and the only option if you want to work with embedded structs (but the newed memory should still be owned by some RAII smart pointer even if it gets passed around as a bare pointer)

While there are atomic instructions, they usually require memory barriers to ensure modern CPUs order the instructions properly to get the desired behavior. This can have a negative effect on overall performance if these atomic ops are hit in hot spot.

Understanding constructors, destructors and RAII is a prerequisite for any real C++ programming. Avoiding shared_ptr for performance reasons before you know it's a bottleneck (it probably isn't) is a premature optimization.

No, I'm not advocating not using shared_ptr's for performance reasons. What I'm trying to say is that reference counting is not a universal solution and it should not be presented as one. It will also add a little bit of complexity to C++ programs and it has some "impedance mismatch" with pass-by-value semantics.

It's as close to a universal solution as you're going to get without a much more intrusive runtime. Obj-C and Python seem to get along just fine with it. I'd say that shared_ptr removes a lot more complexity than it adds in most code. What kind of impedance mismatch do you see with pass-by-value? You should be passing shared_ptr by value.

One of the things I like about C++ is that it gives me choices and I still use raw pointers sometimes but shared_ptr removes a lot of manual memory management noise and makes it much easier to write robust, correct, exception-safe code.

Reply on news.ycombinator.com