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