Re: Fuzzy Union in C++

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
.