Modern C++ Design Generic programming and Design Patterns Applied [closed]

Answer 1

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.

Answer 2

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

Things from this book are not intended for use in Business Logic, they should be implemented in libraries (Boost, Loki, something of your own) and libraries used in Business Logic. This is a different thing "using this tricks in code" or "implement separated library with using this trick and using beautiful libraries 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 demonstrates powerful c++ meta-programming and good training for brain.

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

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 5

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 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.