Are there any books other than Modern C++ Design which describe the techniques of traits and policy classes. Modern C++ Design is difficult to read even for an experienced C++ developer. I am reading C++ Templates: The Complete Guide by David Vandevoorde, Nicolai M. Josuttis. I hope I will understand templates better after reading this book.

QuoteOriginally posted by: ananihdvAre there any books other than Modern C++ Design which describe the techniques of traits and policy classes. Modern C++ Design is difficult to read even for an experienced C++ developer. I am reading C++ Templates: The Complete Guide by David Vandevoorde, Nicolai M. Josuttis. I hope I will understand templates better after reading this book.I agree. The Alex. book contains nuggets but you have to bore through 7 layers of rock. It is written from a CS point-of-view while I would like to see real apps, anyways...Josuttis is excellent for the plumbing for the foundation classes.ananihdvI have 'ported' most of the GOF to a traits/policy form (using templates). It's muuccccch better and more correct than using inheritance. For example, I can create a Command<Receiver, Action> pattern that use the provides/requires interfaces in Visitor pattern. Works like a dream. If you like I can post it. I use it to add command to a GUI...A good way to discover policies, a good question is: "what services does my component provide and what does it require from others?"The following reference might be useful (with thx to an anonymous Wilmotter who gave the original reference)TMP And there's nothing to stop you using Generics and Inheritance in combination

QuoteOriginally posted by: CuchulainnI have 'ported' most of the GOF to a traits/policy form (using templates). It's muuccccch better and more correct than using inheritance. For example, I can create a Command<Receiver, Action> pattern that use the provides/requires interfaces in Visitor pattern. Works like a dream. If you like I can post it. I use it to add command to a GUI...A good way to discover policies, a good question is: "what services does my component provide and what does it require from others?"Let me take a look at your books Introduction to C++ for Financial Engineers and Quantitative Analysts and Financial Instrument Pricing Using C++

QuoteOriginally posted by: ananihdvQuoteOriginally posted by: CuchulainnI have 'ported' most of the GOF to a traits/policy form (using templates). It's muuccccch better and more correct than using inheritance. For example, I can create a Command<Receiver, Action> pattern that use the provides/requires interfaces in Visitor pattern. Works like a dream. If you like I can post it. I use it to add command to a GUI...A good way to discover policies, a good question is: "what services does my component provide and what does it require from others?"Let me take a look at your books Introduction to C++ for Financial Engineers and Quantitative Analysts and Financial Instrument Pricing Using C++Hi,For the record, I must say that the specific example above with policies is *not* in the above 2 books. Have not published it as such.But template and generic programming is discussed in some detail.

Please post the sample code. I want to see some real life T & P code.

QuoteOriginally posted by: ananihdvPlease post the sample code. I want to see some real life T & P code.I think that one difficulty with books on templates is that the authors jump into the code without doing the analysis/rationale/why business first.Anyway, the concern here is to show how to do policies (traits not yet). I will take 2 patterns Command and Visitor. Assume that we have a context hierarchy of Instruments and corresponding Visitor hierarchy (for greeks, for example). Now the (G)UI can use Command which is an action on a receiver, yes? (see GOF)Now GOF 'classico' says 1 class for each Command but that is not necessary if 1) one uses templates 2) use Visitor as the action(). So the command class <requires> certain functioanlity (accept() and visit()) and <provides> (exec()) to its clients. Then we get reusable code. QEDThi is an example of policy-based design (IN TEMPLATES). There are many more examples...here it is:Quotetemplate <class Receiver, class Action> class GenericCommand{ // The ability to assign arbitrary functionality to arbitrary entities public: enum CmdType {no_change, normal, no_undo}; GenericCommand(CmdType type = no_change) { r = 0; a = 0; ctype = type; } GenericCommand(Receiver& rec, Action& action, CmdType type = no_change) { r = &rec; a = &action; ctype = type; } virtual void Execute() { cout << "executing accept\n"; r -> Accept(*a); } CmdType getType() const { return ctype; } protected: Receiver* r; Action* a; CmdType ctype;};