Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.ai.fuzzy    |    Fuzzy logic... all warm and fuzzy-like    |    1,275 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 599 of 1,275    |
|    Maxim S. Shatskih to All    |
|    Re: Fuzzy Logic Operating Systems    |
|    21 Feb 06 14:33:55    |
   
   XPost: alt.os.development   
   From: maxim@storagecraft.com   
      
   > >> No it is a contract violation.   
   > >   
   > > Why is this bad?   
   >   
   > That depends. If your bank breaks the contract and plunders your money,   
      
   I cannot understand how dispatching from a method can be equalled to bank   
   cheating. Really cannot. For me, re-dispatching from the method is a convinient   
   C++ thing, which also exists in several other OO languages - Borland   
   Pascal/Delphi and Java at least.   
      
   More so. In C++, you can use:   
      
   struct Foo   
   {   
    virtual void Print() {   
    printf("Foo!\n");   
    }   
    virtual void DoPrint() {   
    Print();   
    }   
   };   
      
   struct Bar : public Foo   
   {   
    virtual void Print() {   
    printf("Bar!\n");   
    }   
    virtual void DoPrint() {   
    Print();   
    Foo::Print();   
    }   
   };   
      
   - note the Foo::Print() call in the end, it _does not dispatch_. So, C++ has   
   both ways - re-dispatch and no re-dispatch, the second way requires you to   
   specify the base class name explicitly.   
      
   > If you aren't interested in software quality, well, some people would never   
   > board a jet, or drive a car, or turn a computer on.   
      
   Can you be more detailed? For now, you're declaring the loud dogmas. Can you   
   provide me with real-world, "in-metal" demostration of why dispatching from the   
   method is bad? The words "contract violation" are just words.   
      
   > Apart from being wrong   
      
   Why is it wrong? it provides very convinient ways of doing things.   
      
   >, re-dispatch is also very inefficient. Furthermore,   
   > it prevents a lot of optimizations the compiler otherwise might do.   
   > Consider:   
   >   
   > class Numeric   
   > {   
   > public :   
   > virtual Numeric Foo (...)   
   > {   
   > const Numeric X = 1;   
   > const Numeric Y = X + 1; // Can't fold this constant!   
      
   Absolutely artificial case, not a real-world issue.   
      
   > You didn't. You gave an example of a class-wide procedure which dispatches   
   > within its body. It is simple dispatch. No re-dispatch is needed there.   
      
   Why? Both Paint() and GetColor() are virtual, and the base class's   
   implementation of Paint calls GetColor via dispatch. Paint itself is called via   
   dispatch too - it is also virtual and overridable. So, my sample is exactly   
   what is re-dispatch - Paint called via dispatch calls GetColor via dispatch   
   too.   
      
   > Now, putting my software architect's hat on: a need in re-dispatch often   
   > indicates a design problem. C++ let these problems slip undetected. There   
   > is a very common special case, when an abstract method is called from   
   > another method [the latter should be class-wide instead.]   
      
   What is the difference between the "method" and the "class-wide procedure"? Is   
   C++'s virtual member function - a method? or a class-wide procedure? In fact,   
   everything is class-wide in C++.   
      
   > worms. Consider two siblings doing +. Now imagine that this happens in the   
   > brake-by-wire system of *your* car.   
      
   That's why I prefer such systems to be coded in C by competent people (from   
   what I know, they are really mainly such). The language "syntax sugar" we're   
   discussing here _increases_ the number of potential issues to overlook, and   
   your suggestion is to use even more complex languages to deal with it.   
      
   My suggestion is - use C and your brain. Nothing else.   
      
   --   
   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)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca