home bbs files messages ]

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 686 of 1,275   
   Dmitry A. Kazakov to All   
   Re: Fuzzy Union in C++   
   09 Feb 07 09:34:46   
   
   From: mailbox@dmitry-kazakov.de   
      
   On Fri, 09 Feb 2007 08:35:03 +0100, Seweryn Habdank-Wojewódzki wrote:   
      
   > Dmitry A. Kazakov wrote:   
   >   
   >>> And? I understand that you want to say that I will have a problem when   
   >>> there will by inheritance and there I will have a trouble with taking   
   >>> proper virtual function. Yes, you are right, but I do not want to force   
   >>> static case to be dynamic. I never said like that.   
   >>   
   >> No, it is not a virtual function and it never will be overridden. A   
   >> class-wide function cannot be overridden, it is exactly same   
   >> (contravariant) for all members of the class (=derived types).   
   >   
   > So am still do not understand, maybe it is a kind of static function in C++?   
   > Could you give little more code? If it is not a any kind of constructor and   
   > not a static function, and not external function. I do not understand the   
   > context.   
      
   C++ messes that up with virtual functions which behave partially as member   
   subprograms, partially as class-wide subprograms. So from C++ text it is   
   often unclear what was the programmer's intent. The best possible example   
   of a class-wide subprogram in C++ is this:   
      
   class T {...};   
   void Bar (T& X); -- This is a class-wide of T   
      
   Any derived type can call to Bar. The Bar body is same for all of them.   
   From within Bar all calls to the primitive operations of T will dispatch.   
   Bar can call to other class-wide subprograms of T.   
      
   void Foo (T X); -- This is not a class-wide of T   
      
   There is no dispatch from the body of Foo. [ This is one of design faults   
   of C++, because there of course should be no any semantic difference   
   between T and T&. By-value vs. by-reference is orthogonal to type-specific   
   vs. class-wide. It is same as if template would expand only for Foo(T&),   
   but never for Foo(T).]   
      
   >>> For mr all that has no clear formulation of   
   >>> the problem. What is that mean ti is a member of ... This is set of what?   
   >>   
   >> Of types.   
   >>   
   >> class T {...};   
   >> class T1 : public T {...};   
   >> class T2 : public T {...};   
   >> class T3 : public T1 {...};   
   >> ...   
   >   
   > So here we have a construction. And how you can define operators* to reach   
   > our target?   
      
   class T {...};   
   T * operator * (T& Left, T& Right);   
      
   C++ cannot return class-wide objects on the stack (another design fault),   
   so it should be a pointer to, instead.   
      
   >>>> The consequence of this is that there exist good chances that the   
   >>>> representations will be unknown until run-time and required dynamic   
   >>>> switching.   
   >>>   
   >>> And?   
   >>   
   >> => it cannot be switched by a template parameter.   
   >   
   > Of course if it can not be done in runtime (I never told that), but many of   
   > class representation you can do in static contents.   
      
   But you have to know that in advance, before you write the first line of   
   code. With an OO model you don't need to. Further, if later it turns to be   
   indeed static, the compiler could remove any dynamic dispatch from the   
   code. This becomes an optimization issue, rather than a design one. I.e.   
   class-wide programming provides a higher-level abstraction.   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- 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