what was wrong with struct & class in C++?
BC
NOTmi_emayl_adrez at hotmail.com.remove.not
Thu Dec 13 22:55:13 PST 2007
On Thu, 13 Dec 2007 21:13:43 -0000, Walter Bright
<newshound1 at digitalmars.com> wrote:
> BC wrote:
>>> I admit I exaggerated in the original post (or was completely wrong. D
>>> isn't
>>> broken) Perhaps we could consider all this as just thinking out loud.
>>> I have to say I've never really had a problem with slicing (well, maybe
>>> when I was first learning.) Assigning related value types to each
>>> other is
>>> conversion, not polymorphism, if you accept that you're ok. You could
>>> make things more interesting though (or a complete hack). You could
>>> make
>>> all your container types descend from one,
>>> with all virtual functions. In C++ you could then use them as value
>>> types,
>>> and all the functions get called non-virtually or as a reference and
>>> they're all virtual. Admittedly this rules out the non-virtual case if
>>> using null pointers to save memory for empty containers.
>
> Yes, in C++ you can do all that. The issue is that when both value and
> reference semantics are mixed together in one class is that it's almost
> certainly a broken class design. Complicating the problem is the users
> of a class have to be careful to only use it as a value type, or only
> use it as a reference type, per the class implementation. I propose that
> this is an unnecessary burden on both the class designer and the class
> user, and certainly C++ code is susceptible to many insidious bugs
> because of it that are very hard to protect against.
>
>
>>> You could
>>> possibly imagine a third way where a reference (giving you
>>> polymorphism)
>>> simulates value semantics by dupping on every assignment (so you don't
>>> have to worry if two share data).
>> oops, typo, i meant reference counting, obviously.
>> would it be possible to have a way of changing the behaviour of a struct
>> slightly without having to forward all the calls?
>
> The current ideas on doing reference counting in D involve having a
> struct wrap a class reference. Please note that current C++ reference
> counting designs do the same thing - C++ offers no efficiency advantage.
I guess wrapping has most of the same effect as inheritance with
non-virtual calls. Does that mean it will be possible to overload struct
T.opAssign(T) to make the counting more robust?
PS. Will dmc++0x be out early due to already implementing most of it once?
More information about the Digitalmars-d
mailing list