Old problem with performance

Christopher Wright dhasenan at gmail.com
Wed Feb 11 12:28:35 PST 2009


Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> So the problem exists since you are trusting the programmer to avoid it.
> 
> The slicing problem exists in the sense that it is possible for a bad
> programmer to accidentally slice an object.  However:
>   - This is not a problem with the language, but an avoidable programmer
> error in the language.

Yes. There are many examples of this: memory leaks, array bounds errors, 
invalid casts, that sort of thing. If you don't mind explicitly coding 
around these, stay with C or C++. You'll have these errors, but if 
you're careful and disciplined, it won't happen too often. It will, 
however, take time and attention to avoid these errors, and to debug 
them when you slip up.

In some cases, a language change can eliminate a class of bugs. 
Sometimes it's worthwhile. In my experience, the cost of forbidding 
polymorphic value types is pretty much zero.

>   - There are far more common programmer errors in C++ against which D
> does not guard.  For example, dangling pointers to stack variables that
> have gone out of scope.

Yep. Escape analysis is tricky, but I'd like to see it in D.

>   - D's response to this perceived problem is far too heavy-handed,
> because it disallows useful correct code.

Well, D is a systems language, so you can still get the same effect, but 
it's sufficiently difficult and ugly that it is likely not worthwhile. 
On the other hand, you can probably simplify it to a single template 
mixin (see the thread on struct interfaces). Given that it is not a 
common need (as far as I can tell) and is an inherently unsafe thing, I 
believe that it is reasonable.

>   - I would even say that the reference type classes in D lead to more
> problems.  It is very easy for two objects in D to accidentally share
> internal state, something that is impossible with value types.

struct A
{
	int* i;
}

A a, b;
int* i = new int;
a.i = i;
b.i = i;

Hey look, they share internal state!

What mechanism for sharing state is available to by-reference objects 
but not by-value objects?



More information about the Digitalmars-d mailing list