Modern C++ Design Generic programming and Design Patterns Applied

Question

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?

Answer 1

IMHO, reading (and understanding!) the first chapter of the book is useful (I beleive it is even available on-line for free). The rest of the book pretty much describes the internals of Loki library and I don't really recommend it.

Answer 2

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.

Answer 3

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.

Answer 4

If your Company/Project allows boost. This book will help you to uncover some boost magic just for you own satisfaction.

If you Company/Project doesn't allow boost. This book will be a good guide to recreate some boost parts that you need most of all like boost::function.

I believe that in every project there is some kind of utility module. Such book will help you to make your 'utility' more generic and safe by borrowing some books suggested patterns and SFINAE tricks.

And most of all this book will show how you can rethink some of the GOF design patterns changing runtime polymorphism with static.

Answer 5

• What do I use directly from the book? Nothing - I don't use Loki or Boost.
• Has it influenced my code? Not really - I was familiar with the concept of policies before I read the book
• Is it worth reading? Definitely!

Answer 6

To me it was more of a mind-broadening experience. I read through the book and kept learning details and tricks, some of which I have used later. But the most important part is that Design with capital D is discussed in the book all along (no pun intended with the D language).

The chapter on smart pointers switch my 'provide all possible functionalities' mindset to a more conservative: consider what you offer, is it worth it? how can it break the code? will it help the user? will it make code fragile by creating subtle pitfalls?

The part of policy based design should make you thing while designing whether your classes could/should be better divided into smaller orthogonal units. While in most cases I don't end dividing into all those policy classes, the code usually ends up being cleaner as different orthogonal pieces get less entangled.

Oh, as Earwicker, my first reaction was implementing fancy stuff that really speeded part of the development, but then again, in the small company I work for I am the only one able to maintain it and that really is a problem. Don't over do it. It takes twice the brains to debug and maintain than it took to develop.

Answer 7

I didn't used Loki but I've actively used boost on my previous work. Boost have implemented many ideas from this nice book;

Things from this book are not intended for use in Busines Logic, they are should be implemented in libraries (Boost, Loki, something your own) and libraries will used in Bisnes Logic. This is different things "using this tricks in code" or "implement separated library with using this tricks and using beautifull library in most of your code (for example boost::bind - ugly implementation but nice in usage - but you almost never see this implementation)"

Also this book demostrate powerfull of c++ methaprogramming and good training for brain.

Answer 8

I did experience some rude reactions from people when I stated using stuff from Modern C++ design. First, WTF comments. This was followed by 'don't try to be too smart' comments. Then, a better understanding of the ideas. And then, finally, acceptance of the ideas to the point where they are a part of the common vocabulary.

Make sure to keep multiple copies of this book handy. Ideally, buy a copy for every developer. Also, until this stuff becomes common vocabulary among the developers, cite the pattern/idiom and the relevant pages in your comments.