QuoteOriginally posted by: pcaspersQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: pcaspersQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: pcaspersso TMP = template method pattern or TMP = template meta programming ? :-)The second is probably senior. The 1st is just a shorthand.I thought "template method pattern" refers to a specific design pattern. Anyway.Indeed.But template meta programming does not.Yes, I don't know why it entered the discussion maybe the acronym TMP.TMP design patternTMP metaprogramming technique?

QuoteOriginally posted by: CuchulainnYes, I don't know why it entered the discussion maybe the acronym TMP.TMP design patternTMP metaprogramming technique? :)seems outrun brought it up

CRTP is nice but the template parameter Base<T> is kind of restrictive. I has a think about pushing <T> into a template member function. This is more maintainable that classic CRTP. Maybe useful to you.(had a bit of time because it's been raining her for the last 2 weeks )

thanks, I will have a look. Ah, Holland, not more than 20km away from my home town, still quite another world already

(double)

Quote In the CAD experiment we did heterogenous containers gave a speedup of a factor two over CRTP and much better optimization control IMOFor the record, my company has been writing CAD production systems since 1992 and we used subtype polymorphism with no performance issues. The thing to remember here is that the virtual function overhead is negligible compared to the algorithm it implements. Typical algorithms are collision detection between objects, polyline intersections, rendering etc. and vtabls are the least of your worries,.It would be micro-optimization and _expen$ive_ to port the code. The customer won't pay. For him, it is over-engineering. For PDE/FDM I would favour CRTP and Template Method Pattern.QuoteVery rarely one doesn't know the type compiletimeCare to rephrase that? Does it mean "in almost all cases we know the type at compile time". If yes, then I don't agree/it is not true in general. Just think of a Composite object. We don't want to know the type at compile or run time.

These are lightweight operations. Try computing centre of gravity of a composite shape,

QuoteOriginally posted by: outrunAll your restriction (1992 systems, customer won't pay) have nothing to do with this topic, I'm just presenting a different design pattern and some stats, thats all. No need to get defensive, it's not about you. Besides (a little?) performance, the main problem is using (overloaded) member functions that should be non-member functions. Use center_of_gravity(obj); instead of obj.center_of_gravity().. Especially when you want to have a design where you want to add new operators in the future in a maintainable way.:beer;You miss the point. Most current CAD and I reckon finance class hierarchies do not use your ideas. And they probably never will for the reasons alluded to.You may have a great technical solution, but the problem is persuasion.Quotethe main problem is using (overloaded) member functions that should be non-member functionsHow can we test the vailidity of his assumption? How can you convince all those doubting Thomases? Enough ideology; how would you implement Craig Sneyd using non-members?

back to the original question, if the compiler "knows" that the reference to the base class is constant, i.e. something likeA const * p orconst shared_ptr<A> p orconst QuantLib::Handle<A> pwouldn't then virtual callsp->someMethod()be easily optimized so that one wouldn't gain anything by crtp ?

but it only has to be done once (at runtime, yes), since the object pointed to won't change ?