Old problem with performance
Derek Parnell
derek at psych.ward
Sun Feb 8 14:59:05 PST 2009
On Sun, 08 Feb 2009 14:37:18 -0800, Walter Bright wrote:
> Derek Parnell wrote:
>> On Sun, 08 Feb 2009 11:13:00 -0800, Walter Bright wrote:
>>
>>> In particular, classes are *meant* to be used as reference types, but
>>> the program is trying to treat them as value types. Virtual functions
>>> are orthogonal to what value types are - a continuing problem C++
>>> programs have is conflating value types with reference types.
>>
>> In D, what is the recommend technique to derive one user-defined value type
>> from another?
>
> There isn't one. Deriving types only makes sense when expecting
> polymorphic behavior, which is completely orthogonal to the whole idea
> of a value type. A polymorphic type should be a reference type.
Thank you. I was using "derive" in the English language sense rather than
the O-O sense, but I get your point - for example a 'currency' value type
is only ever to be used as a currency value and not any of its base value
types.
Fair enough.
> A value type can have *aggregation*, however, as in:
>
> struct Sbase
> {
> ... base members ...
> }
>
> struct S
> {
> Sbase base;
> ... more members ...
> }
>
> You can also embed interfaces in a struct:
>
> interface I { ... }
> struct S
> {
> I i;
> }
This is what I thought too. In D, a value type can be derived from another
value type by using a combination of data aggregation (data inheritance if
you will) and interface aggregation (method inheritance?).
I feel that D could do with a little more syntax support for derived value
types though, because at times it is a bit awkward and/or verbose. I'll dig
up some examples of what I mean.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
More information about the Digitalmars-d
mailing list