what was wrong with struct & class in C++?

Walter Bright newshound1 at digitalmars.com
Thu Dec 13 13:13:43 PST 2007


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.



More information about the Digitalmars-d mailing list