From: mailbox@dmitry-kazakov.de   
      
   On Mon, 12 Feb 2007 22:51:56 +0100, Seweryn Habdank-Wojewódzki wrote:   
      
   > Dmitry A. Kazakov wrote:   
   >   
   > The point is that pass value by reference is   
   > similar to work on pointers, and pass by value is other.   
      
   Not at all. Pointer is an object of a different type (and thus with a   
   different value). Parameter passing is an implementation detail irrelevant   
   to the program semantics. This means precisely that programs exploiting   
   differences between passing immutable objects by value vs. by reference are   
   erroneous.   
      
   Further you are confusing C++ references in the meaning "object renaming /   
   aliasing" with C++ references in the meaning "parameter passing mode."   
   These are not fully equivalent. To throw them into one bowl was a quite bad   
   idea. Observe that renaming potentially might mean by value. As an example   
   consider a renamed bit of a Boolean array of the length 32 kept in a   
   machine register. This is a fully legal construct, not in C++, but in other   
   languages. In this case access to that Boolean object would mean copy-out /   
   masking / modification / copy-in.   
      
   [ One of big design faults of C++, which prevents many good optimization,   
   is messing up with the issues of aliasing. ]   
      
   >>> 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.   
   >   
   > It is a matter of view.   
      
   I don't see how it could be a matter of view. Either the object can be   
   allocated on the stack or not.   
      
   > The more important matter is - if it is a real trouble in the   
   > language?   
      
   Sure. Firstly, is a huge performance hit. Secondly it is a great safety   
   problem, because it enforces the programmer to use pointers with all   
   consequent problems of.   
      
   > And IMHO this is just a matter of notation. Especially if you are   
   > using auto_ptr, you do not need to remember to delete pointer to object. So   
   > passing class-wide objects can be not as dangerous for different nasty   
   > construction like pure pointer e.g. when in destructur exception can occurs   
   > (what is really nasty, bo auto_ptr and other intelligent pointers can   
   > handles).   
      
   No, smart pointers are objects themselves. The problem well applies to   
   them, because in the case of a hierarchy of pointer types, you were unable   
   to return a pointer of an unknown specific pointer type on the stack.   
      
   >>> 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.   
   >   
   > No. I need even less than in OO.   
      
   How so? Your example does not show it.   
      
   [...]   
   > Dynamically you can not use func(1).   
      
   Why should I? It is not a member of the class foo.   
      
   > Moreover consider situation when you   
   > have many types of argument, so there are two choices either define all   
   > possible func(...)   
      
   No, this is ad-hockery. Software analysis and design presumes up-front   
   consideration of what should be classes and which primitive operations they   
   have. This is exactly same for both static classes of generic template   
   parameters and dynamic classes of types. In both cases the programmer's   
   responsibility is to identify the class and to consider its behavior.   
      
   >> 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.   
   >   
   > Yes. But similar level of abstraction you could reach by static   
   > polymorphism - of course with respect to compile time.   
      
   The level of abstraction is irrelevant to the point of early design   
   decision making. Further, the purpose of any higher abstraction is to   
   postpone, if not eliminate, the need in making such premature [and   
   low-level] decisions. Templates clearly fail here. They impose a design   
   constraint.   
      
   > By the way. Look on the API of javax.swing.text.html.ListView Java 6 class.   
      
   I can't comment on the design of Java libraries. From people worked with   
   them I heard that it is quite poor. This does not justify design flaws of   
   C++. Neither it does the concept of source code preprocessing.   
      
   --   
   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)