QuoteOriginally posted by: CuchulainnQuoteread Alexandrescu The concepts in this book are interesting (my favourite is chapter 1) and most have been implemented in the boost, so I see no point in using Loki. boost will be a part of standard C++.I never said use Loki, and yes I rely on some boost headers quite a lot. However there's a world of difference between using boost as a magic canned solution and understanding how to actually do this kind of thing. The first 3 chapters of A. were a revelation - showed to me a whole side of C++ you seldom see elsewhere, so that now I can do these tricks when I need them, eg. strip constness from a template parameter, or have a templated class Typer with a local typedef inside it so that Typer(a)::InnerType is the type of a .Talking about which, is there a good reason why boost::any doesn't have such a local typedef that remembers the original type of the object - only a cast that fails if the type is wrong?Oh yes, and when someone tells me Java generics are in the least comparable to C++ templates, I just laugh.

QuoteTalking about which, is there a good reason why boost::any doesn't have such a local typedef that remembers the original type of the object - only a cast that fails if the type is wrong?I think it comes with the territory. Maybe boost.Variant is more suitable because it uses a bounded set of user types. Sometimes you want to know the types in a container, sometimes not.Any uses _indiscriminated_ types (aka void* on steroids) while Variant uses _discriminated_ types. This could be the reason.QuoteOh yes, and when someone tells me Java generics are in the least comparable to C++ templates, I just laugh.Java generics were an afterthought in the design, with the corresponding consequences.The design error IMO is that at the time, the Java designers implicitly assumed (incorrectly) that everything is an object. C++ programmers knew that there is more than objects for 25 years now.And, at the time Java designers found no reason for operator overloading...

MJ's book!Its thin, and covers 'most all the important concepts.You might also want to read a book on STL separately.

QuoteYou might also want to read a book on STL separately.Replace 'might' by 'MUST'. At least 70% of C++ is templates these days. And class hierarchies are used less and less, certainly compared to the heydays of the 90's.

QuoteOriginally posted by: veeruthakurMJ's book!Its thin, and covers 'most all the important concepts.I would disagree vehemently. It's thin, yes, and does a decent job on OO and basic design patterns, but really is pretty useless on templates in general and STL specifically. I could get by in C++ pretty well without _ever_ using inheritance (by using policy templates instead where I have to - though clearly there are many cases where inheritance is the better choice), however C++ would _not_ be a usable language without templates IMO.

My book is intended to teach those who can crawl in C++, how to walk. I believe it does this effectively. My main objective was to teach the reader how to think in a certain way, anything beyond that is a bonus. Personally I use templates for generic programming but template meta-programming leaves me cold. But that's my personal style only. I have read Alexandrescu and think it's an interesting book but I don't use the techniques much. As those who have looked at my list of recommended books will notice, I think you need to read a rather large number of books on C++ to be competent in the language.

Yep, I wasn't knocking the book, merely saying it should in no case be the only book on C++ one reads, which it looks like we agree on

QuoteI could get by in C++ pretty well without _ever_ using inheritance (by using policy templates instead where I have to - though clearly there are many cases where inheritance is the better choice), however C++ would _not_ be a usable language without templates IMO. Classical inheritance is the implementation of the Gen/Spec semantic relationship between entities/classes. It has two forms, namely interface (pure functions) and implementation inheritance, the latter not always leading to maintainable or even correct class hierarchies. The OO literature is strewn with many of these incorrect examples. Classical inheritance is extremely useful for Whole-Part product hierarachies in CAD and process industry, for example, where specialised classes has extra structure with respect to direct and indirect base classes. But is is not correct to create derived classes based on the criterion that they have extra attributes/data wrt base classes. In this case I use data-driven pattern and the Boost libraries Any, Tuple and Variant fit the bill with distinction. This is a kind of polymorphic data. When defining member functions, I prefer Policies (parametric polymorphism) on the one hand and Visitor pattern (subtype polymorphism) on the other hand. Inheritance is OK, but it may be wrong in some cases (e.g. when it does not model an ISA hierarchy) and other, generic policy-based methods may be superior.

I have been using both the DUFFY books (Fin instrument pricing... & Intro to ....) IMHO, one shouldn't rush into Duffy / Mark Joshi /QuantLib without studying Basics of STL, Design patterns,Basics of STL, & TEMPLATESI restricted myself to Facade,Adapter,Visitor,Factory, Template Method & Strategy. It helps enormouslyAlso, read Scote Meyers' "More Effective C++" if possiblehttp://www.cplusplus.com/doc/tutorial/http://www.learncpp.com/

Quoteone shouldn't rush into Fair enough.This means that most books start at conceptual level N (N >=1) and some readers have knowledge up to level M (M < N). Can you describe what these books are missing (concepts, examples, etc.), so levels M+1, .., N -1.thanks One thing I did notice is that most students think procedural (which btw is also fine) but not really in an OO way. true? QuoteI restricted myself to Facade,Adapter,Visitor,Factory, Template Method & Strategy. It helps enormouslyThese are the most useful IMO as well. Visitor in particular.20-80% ruleThe POSA Whole-Part pattern is for bigger apps and subsumes all the GOF ones.

Although I like the Duffy book, it is vitally important that you read several, simply because it is such a big subject, and although Duffy has a valid perspective, it is far from the only one.I'd guess 60% of what you need to know to get through a C++ interview is not in Duffy, and the same applies to almost all other texts.People criticise the Stroustrup book for good and bad reasons, but it does hit upon nearly everything you need to know about C++ itself, so you must get a copy if you are going to self teach.Also all text books (except that by Justin London) have clear, relatively high quality code.Real C++ (or C# or Java) just ain't like that.The same "criticism" may be used against QuantLib, it's nearer to how finance code should be rather than how it is in the firms you want to work in.There are many open source projects which can give you experience dealing with complex real situations.

CuchulainnWhat the N type books (like yours) seem to be missing are much more code snippets on C++ syntax issues.For any newbie, simply getting to know the scope of C++ (including STL,Design Patterns) is mind bogglingBut, I dont feel that N type books should (& can) address C++ syntax to that extent.Its upto the reader to come well-prepared for such booksI have noticed that all the basic books on C++ (Deitel, Strustrup, Lippman etc) explain Inheritance (is-a) in great detail.But they totally miss COMPOSITION/AGGREGATION (has-a). Books like yours & MJ could address this before introducing Design PatternsBTW: "Fin Instr Pricing..." covered DesignPatterns much better than "Intro to C++....."Quote------------------------------------------------------------------------------------------------------------------------------------One thing I did notice is that most students think procedural (which btw is also fine) but not really in an OO way. true? -------------------------------------------------------------------------------------------------------------------------------------That is true. I think ,the reason for this is Virtual functions. They learn the syntax, but miss the purpose & usefulness in OO. They dont realise that designing Pricing Libraries is impossible without OO (& ofcourse Polymorphism).

Amit,Thanks for the feedback.Putting much syntax and apps in one book is always a great challenge for many reasons. Most books do indeed concentrate on syntax and that maybe due to the background of authors. For me, I have nearly always been involved with products (apps), so syntax is a means to an end, and others explain it better; mind you I hate many examples I see in books (small rant here). I must admit that C++ - with all whistles and bells - must be daunting. One the other hand, I reckon you have the time (just like I had when I was young ) In the old days I used to use concept map to find aggregaton, inheritance relationships between classes and then progress to virtual functions. CM help!concept map QuoteConcept maps are used to stimulate the generation of ideas, and are believed to aid creativity. For example, concept mapping is sometimes used for brain-storming. Although they are often personalized and idiosyncratic, concept maps can be used to communicate complex ideas.Formalized concept maps are used in software design, where a common usage is Unified Modeling Language diagramming amongst similar conventions and development methodologies.

QuoteOriginally posted by: amitkQuote------------------------------------------------------------------------------------------------------------------------------------One thing I did notice is that most students think procedural (which btw is also fine) but not really in an OO way. true? -------------------------------------------------------------------------------------------------------------------------------------That is true. I think ,the reason for this is Virtual functions. They learn the syntax, but miss the purpose & usefulness in OO. They dont realise that designing Pricing Libraries is impossible without OO (& ofcourse Polymorphism).the main objective of my book was to get the reader to think OO.

One experience is that Design Patterns start to make sense (only?) after you have made the same programming mistake (at least twice). Example: v1, you have developed a specific algorithm A1 that works with an option and you realise that is must be replaced by another one A2, but this entaill changing the code, data etc. etc. What we would haved liked is to quarantine A1 and A2 in their own little worlds, derive them from a common base class and let client code access this base class using composition.Then .... you have discovered the Stategy pattern. Only 22 patterns to go! So, don't worry about DP just in the beginning, it will come. Make a few mistakes...