XPost: alt.os.development   
   From: maxim@storagecraft.com   
      
       Sorry Dmitry, I'm asking now :-) not continuing the argument about theory   
   and practice. :-)   
       Thank you very much for providing me with this information, very   
   interesting and valuable (for my personal professional growth :-) ).   
      
   > The pattern you are trying to express in C++ is:   
   >   
   >    type Printable is tagged ...   
   >    procedure DoPrint (What : Printable'Class);   
   >    procedure Print (What : Printable) is abstract;   
   >   
   > DoPrint is class-wide. It works for all types derived from Foo. It has the   
   > same implementation for all of them:   
      
   So, the term "class-wide" means nearly the same, as "non-virtual" in C++? The   
   method, which is called without dispatch?   
      
   > DoPrint is not a method. It cannot be overridden. The contract of DoPrint   
   > is: "give me anything Printable."   
      
   Is this the same as with non-virtual member functions in C++?   
      
   > > Can you be more detailed?   
   >   
   > No. It's confidential information.   
      
   No :-) I'm not speaking about _your exact job tasks_. I'm speaking about _why   
   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?   
      
   > A polymorphic subroutine has the body distributed over particular derived   
   > types. Derived types are responsible for corresponding implementations of.   
   > They have to override it. [ Method inheritance is a special case of   
   > automatic overriding. ] Polymorphic subroutine is covariant in the   
   > corresponding argument (result).   
   >   
   > A non-polymorphic subroutine has one body. When it is defined for all   
   > derived types, then is called class-wide. Non-polymorphic subroutine is   
   > contravariant in the corresponding argument (result).   
      
   Thanks!   
      
   > This shows how inconsistent C++'s model is. By-value vs. by-reference   
   > clearly has nothing to do with the issue.   
      
   Even Stroustrup himself said something about "the language already has pointers   
   with all operations over them, so, we will not create yet another set of   
   operators for references". Yes, reference is 2nd class citizen in C++, and -   
   from this description of Stroustrup - I feel a bit of his regret about   
   "probably they are not needed at all, but they are too good in some particular   
   cases, so we will include them to the language as a general notion".   
      
   The "particular cases" IMHO (I agree I can be wrong here :-)) are parameters   
   and retvals passed by ref _in operator overload functions_. For instance, it is   
   suggested (though not mandated) that operator[] will be used in lvalue   
   contexts. So, it must return lvalue. Same way - operator++ is suggested to   
   update the lvalue (not value) passed to it, and to require the lvalue. So, it   
   must take the lvalue as parameter.   
      
   C++ references seems to be a way to pass lvalues as parameters and retvals,   
   which is mostly needed for operator overload only. I see no advantages of refs   
   over pointers in any other context, and see the major disadvantage - lack of   
   visual reminder "&" when passing the parameter by ref, which decreases the code   
   readability.   
      
   > the heap instead. This is also why a polymorphic object cannot be copied in   
   > C++:   
      
   IIRC operator= (which is copying) can be virtual in C++, which means that the   
   object can be copied. Well.... it is not so good:   
      
   class B   
   {   
   virtual void operator=(B&);   
   };   
   class D   
   {   
   virtual void operator=(B&);   
   };   
      
   - then the D's "operator=" will accept any object of class B, and thus can only   
   copy the "B's part of D", and not the whole D. This can only be solved by   
   having the D::operator=(D&) function, but is does not matches the   
   B::operator=(B&) in signature, so, the vtbl dispatch cannot be used to call it,   
   only the static type knowledge of the compiler, which is not always available   
   and not available for a polymorphic object.   
      
   In fact, C++ can only dispatch based on "this" hidden parameter type only, and   
   not on parameter types and not on retval types (retval type is even not a part   
   of the signature in C++, it is not used in choosing among several functions   
   with the same name).   
      
   BTW - what is the theoretical term of C++'s choosing among the functions with   
   the same name based on signature? It is different thing then a call thru vtbl,   
   which is called "dispatch". How is it called?   
      
   Is it what you're speaking about? Yes, in practice, having a "virtual B*   
   Base::Copy();" method is the only good way of polymorphic object copy in C++.   
   This is probably bad from the theoretical point of view.   
      
   Also about initialization (unlike copying). Copy constructor really cannot be   
   virtual, as any constructor. You will need something like the RTTI's class   
   info's CreateInstance method to do the correct copy of the polymorphic objects.   
      
   > void Foo (T& X)   
   > {   
   >    T Y = X; // Not a copy! T isn't T'Class   
      
   This is initialization and not copying. If you have the T::T(T&) copy   
   constructor, then it is:   
      
       Y.CopyConstructor(memory location pointed by the reference X);   
      
   I see no problems here, unless the X parameter is really a reference to the   
   object of the type _derived_ from T and auto-casted to T& in the position of   
   the call parameter. In this case, only the "T part" of the object will be   
   copied, which is probably bad.   
      
   > canceled long before software deployment! (:-)) [ Developing costs in ANSI   
   > C are extremely high for a quite poor quality. As for maintenance costs...]   
      
   And what language is good for the tasks of developing the car's software?   
      
   Languages like Java or Smalltalk or Perl or C# are definitely not for embedded   
   and firmware development. So, I assume you mean Ada. Correct?   
      
   It is interesting - then why most OSes were developed in C? I think Ada was   
   already here in ~1989 when the work on Windows NT started, and it was already   
   here when Linus started his Linux. Why the Ada OS is not here and have not   
   beaten these 2 ones due to lesser development and maintenance costs? Why the   
   whole world of programmers (and especially their managers) did not turn to Ada   
   due to its lower development and maintenance costs? What is your explanation?   
      
   Also, Dmitry, what do you think about inheritance? I've heard the following   
   (roughly) opinion once from one software architect - "the original old   
   historical OO paradigm treated inheritance as one of the 3 corner stones. But   
   now, it is not so. The thing is that software architecting is managing   
   _dependencies_ between components, which means - imposing some order and   
   restrictions on them, so they remain manageable and not grow into the   
   unmanageable pile of dirt. This effectively means - imposing strong contracts   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)