Igor.Smirnov@cern.ch write:
But should the destructor of D and T be declared as "virtual" in order to make this work? If yes, this going to be "intrusive" detail anyway!
Indeed, but this is part of the language.
Regarding the second one, is this correct to write:
class T{...} class D: public class T {...}
D my_derived_object; T& my_reference = my_derived_object; template<typename T> Container( my_reference);
[snip] That's not valid C++. Yet I still see what you mean, and I explained that problem several times months ago in my original message and in this thread.
I do not understand, why you propose value object but not smart pointer?
Since we deep-copy, we've got value semantics. Better make this a value than a pointer, then. Plus, it is well known that pointers are sources of unsafety. By completely hiding pointers from the interfaces, safety is gained.
How do you plan to access these objects and the functions of them? Through "."?
Unfortunately, operator. is not overloadable. So you'd have to use operator->. You could have seen that in the implementation and examples I provided.
How do you provide that the correct instance of virtual function is called, that is from type D?
The member functions must be virtual for them to be dynamically dispatched to the appropriate ones. It simply forward operator-> to the pointer to the base.
Why do you need this, at all?
There is a motivation part at the beginning of my first message.
Indeed, the notation "->" is used to indicate possible call of virtual function, whereas "." is always understood as fixed call (if I understand correctly, correct me if not).
operator. has nothing to do with "fixed calls". It is not the case, for example, when using references.
So when you deal with polimorphic objects, it is better to do through (smart) pointers. Why do you want to mix this?
Polymorphic value objects are a type of smart pointers, except that they have a value interface, not a pointer one.
I also can not undesrand the code from your first mail.
It's perfectly standard C++, and very simplistic. It's a very thin layer and easy to maintain. Have you ever looked at the code of a boost library? It's usually much more complicated.