XPost: alt.os.development   
   From: maxim@storagecraft.com   
      
   > > re dispatch from the method is evil_. Can you show some sample or just   
   > > explain - what bad things arise from this re-dispatch? I have shown the   
   >sample   
   > > when the 2 virtual member functions calling one another is convinient - the   
   > > descendants can override either the "smaller" or the "larger" one. What are   
   >the   
   > > contra-arguments?   
   >   
   > The question is why do you need to check the specific type more than once?   
   > What sort of algorithm or objects relationship could require that? It is   
   > quite difficult to find a case where you'd really wished such thing.   
      
   Why? It is convinient, and the perf implication of dispatch in C++ is tiny and   
   usually neglectable.   
      
   It is convinient, because allows the descendants to override either "small" or   
   "large" function, which gives more tools to the hands of the descendant   
   developer.   
      
   > no one [your example, doesn't need it.]   
      
   And what do you suggest in my example? what is your replacement to it?   
      
   >Each time I thought, yes it is, I   
   > was able to find a *better* design.   
      
   What is a better desing in my case? Like - you have the virtual methods   
   GetColor and Paint, and want to allow to override both of them, so that the   
   "simple" descendant will reuse the base's Paint but have overriden GetColor,   
   and the "complext" descendant will override Paint itself and possibly not use   
   GetColor at all.   
      
   > 1. You need a type tag (vtab pointer) allocated in specific objects   
      
   Is it possibly _at all_ to have polymorphic objects without having per-object   
   metadata?   
      
   > 2. You have unnecessary performance hit in specific methods decomposed into   
   > other methods. Because each internal call is dispatching.   
      
   Dispatch in C++ is a neglectable performance hit, especially on modern CPUs.   
   "call [ecx]" vs. "call 0x01347f00" have the same speed, maybe call [ecx] is   
   even faster due to lesser fetching.   
      
   > is wrong. So there should only be parameter modes in, out, in-out. The   
   > compiler should be free to choose the best fit mode. For some types the   
   > programmer should be able to say: look, objects of this type will have   
   > identity, or they are not copyable. These will be always by-reference.   
      
   Looks good.   
      
   > The problem is that C++ has no multiple dispatch.   
      
   Oh, yes, correct, I considered the same after posting the previous message to   
   the forums :-)   
      
   Yes, really the fully polymorphic "operator=" will require multiple dispatch,   
   both on "this" type and on the parameter type.   
      
   >Assignment is a classical example of a multi-method.   
      
   What book can you recommend on the underlying theory of all of this, where the   
   terms of "dispatch", "multi-method", "covariant" in terms of function   
   parameters and such are defined?   
      
   > Yep. If T and T'Class are different types, then they should have different   
      
   What does the term "T'Class" means? "T or any, possibly indirect, descendant of   
   T"?   
      
   > Mine is one from Bible: we a damned. C is a punishment sent us for our   
   > sins! (:-))   
      
   :-)   
      
   > The problem is beyond any existing language.   
      
   OK, thank you once more.   
      
   --   
   Maxim Shatskih, Windows DDK MVP   
   StorageCraft Corporation   
   maxim@storagecraft.com   
   http://www.storagecraft.com   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)