Modern C++ Design Generic programming and Design Patterns Applied


I have purchase this book for our group in the company, perhaps, to improve our design skills and ultimately have a better programming practices. As I read it, I find, mostly, a set of nifty tricks that can be used with template, and not sure if it is worthwhile - and not detrimental-to incorporate it into our code thus introducing code complexity/readability and un-maintainability.

I would like to find out from follow practitioners, what do you use from that book? What is relevant and important to professional software development, what should be avoided?

General thought about this book and how it fits into software development of large-scale system (on the same them, I love John Lakos book)?

What is the Alexandrescu effect?

3/17/2009 10:16:47 PM

Accepted Answer

Outside of standard template uses, the operation I find most useful about the information talked about generic C++ programming, is the ability to use templates to create compile time errors for invalid code scenarios. Once you get the hang of it you can become very efficient at turning a class of what would be a runtime bug into a compile time error.

I've had a lot of success doing that at work. Sure it produces completely unreadable messages and my coworkers occasionally drop by and say "what in the world is that?". But every time it was a bug and they weren't able to compile it. I also heavily comment the particular errors in the hope that it's moderately understandable.

3/17/2009 9:06:08 PM

Around 2005 I got heavily into expression templates and various compile-time tricks for making libraries that were very expressive to use, like internal domain-specific languages embedded in C++. In particular a fairly complete embedded SQL thing, similar to what has since come out as Linq on .NET.

For users, it's fine. But for anyone else apart from me trying to maintain it, it presented a massively steep learning curve. So that's the problem with it; like any "clever" technique, it reduces the pool of people who can maintain it.

This is fine for widely-used class libraries, which general users never need to understand the guts of. But for "in house" libraries owned by a specific team, they probably all need to be able to patch it or extend it sensibly. The more arcane possibilities of C++ templates seem to preclude this, in my experience.

It was a lot of fun though.

Licensed under: CC-BY-SA with attribution
Not affiliated with: Stack Overflow