On Thu, 22 Oct 2009 12:50:21 -0400, grauzone <[email protected]> wrote:
dsimcha wrote:
== Quote from grauzone ([email protected])'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 { ... }")
Your original question was about the statement "scope x = new X()", which
can be done on any type of class, even non-scope ones.
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"?
Passing struct pointers is not always the norm. Passing class references
*is* the norm (and actually the only way), even for scope classes, so
there is much more chance for escape.
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.
You have to go out of your way to pass a struct by reference. You *can't*
possibly pass a class by value, so they are more dangerous.
In order to make scope safer, it has to be a type modifier in addition to
a storage class, so the compiler can make reasonable decisions (like
disallowing implicit casting to a non-scope version).
<OT>
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...
All objects have a *placeholder* for a lock, which isn't allocated until
the object is locked for the first time. It's a very pervasive idea in
other successful languages like Java and C#. Having used it extensively
in C#, I find it very easy to use and well designed.
However, in C#, there is support for conditions on objects as well, which
isn't "builtin" for D. IMO, mutexes without conditions is severely
limiting. The library condition variables aren't as nice as C#'s builtin
conditions.
</OT>
-Steve
