this() not executing code on structs

grauzone none at example.net
Thu Oct 22 09:50:21 PDT 2009


dsimcha wrote:
> == Quote from grauzone (none at example.net)'s article
>> Andrei Alexandrescu wrote:
>> I'd really like to know why "scope x = new X();" is "unsafe", while
>> encouraging doing exactly the same with structs seems to be a perfectly
>> fine idea. Allocating structs on the stack is obviously not any safer
>> than with classes. I don't remember the exact reasons why you wanted to
>> turn "scope" into a library feature, but I think I remember something
>> about discouraging it for safety reasons; please forgive me is this is
>> wrong.
> 
> Because classes in D are always passed by pointer.  (Technically references, but
> really they're just pointers under the hood.)  Returning a scope (stack-allocated)
> class from a function is equivalent to escaping a pointer to a stack variable.
> Returning a struct is done by value, just like returning an int.

(I'm talking about scope classes as declared in "scope class T { ... }")

But you can't return scope classes from a function. You can't pass them 
as ref parameters either. They're designed to be safe.

On the other hand, you can pass struct pointers all the way you want 
around, and it's damn unsafe.

I don't get this "structs are safe because they are value types" 
argument anyway, because the this pointer for structs is a 
pointer/reference anyway. If it's trivial to break that "safety", can 
you really call it "safety"?

> Classes can't be value types because they are polymorphic, meaning their size
> isn't known at compile time.  C++ tries to make them value types but really, there
> is no *good* way to make a polymorphic type with size not known at compile time a
> value type.
> 
>> Why do you want to add class functionality to structs to enable "RAII"
>> like features, when you could just use scope classes?
> 
> To me, this makes perfect sense.  Classes are polymorphic, structs are value
> types.  Except in the "here be dragons" world of C++, the two are mutually
> exclusive, which is the reason for the dichotomy in the first place.  Therefore,
> structs should do everything they can w/o being polymorphic and classes should do
> everything they can w/o being value types.  You then decide which one you want
> based on whether you need value semantics or polymorphism more.
> 
> The only place in D where this logic breaks down is monitor objects on classes.
> Even here, while structs technically *could* be given monitors, this is
> inefficient because they are value types, whereas the efficiency loss from storing
> a few extra bytes in a reference type is minimal in most cases.

Why do all objects have monitor pointers anyway? The idea, that every 
object can act as lock, is a really bad one. But this is off-topic...

> Scope is really a dangerous hack to allocate a *reference type* on the stack.
> It's dangerous and kludgey, but in a performance-oriented language it's a
> necessary evil.

You could say the same about structs.



More information about the Digitalmars-d mailing list