Modern C++ Design Generic programming and Design P

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 2 years ago.

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

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 2

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 3

• 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 4

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

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.