www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - important proposal: scope keyword for class members

reply John Simon <zildjohn01 gmail.com> writes:
I'd like to propose a new use for the 'scope' keyword within an aggregate body.

Members of class type declared with the scope keyword are allocated not as
references or pointers, but initialized directly inside the container.  Instead
of a default initializer of 'null', it will initialize with the default
constructor of the class, or an optional assignment after the declaration. Any
'new [type]' within the assignment will resolve to a simple call to the type's
__ctor, instead of a memory allocation.

Example:

class Inner {
    this() {}
    this(int x) {}
}

class Container {
    Inner i1; // initialized to null
    scope Inner i2; // allocated within class
    scope i3 = new Inner(42); // allocated within class

    this() {
        // implicit i2.__ctor();
        // i3.__ctor(42) written above, executed here
        assert(i1 is null);
        assert(i2 !is null);
        i1 = new Inner;
    }

    this(int overloaded) {
        // i2 and i3 are constructed, same as above
    }

    ~this() {
        // implicit i2.__dtor();
        // implicit i3.__dtor();
        // i1 is still somewhere in the heap
    }
}

IN ENGLISH:

If it's likely that class members will be constructed with and die with the
object, why not just allocate them right in the class? Save on heap
fragmentation and cache misses.  I was honesetly flabberghasted when I realized
there was no way to do this in D, it seems like it should be one of the most
basic constructs of a C-derived (or any low-ish level) language.

The programmer knows best where he wants his objects stored. Also, the 'scope'
makes sense, and we should mirror the current behavior of the keyword in
function bodies.
Mar 06 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from John Simon (zildjohn01 gmail.com)'s article
 I'd like to propose a new use for the 'scope' keyword within an aggregate body.
 Members of class type declared with the scope keyword are allocated not as

a default initializer of 'null', it will initialize with the default constructor of the class, or an optional assignment after the declaration. Any 'new [type]' within the assignment will resolve to a simple call to the type's __ctor, instead of a memory allocation.
 Example:
 class Inner {
     this() {}
     this(int x) {}
 }
 class Container {
     Inner i1; // initialized to null
     scope Inner i2; // allocated within class
     scope i3 = new Inner(42); // allocated within class
     this() {
         // implicit i2.__ctor();
         // i3.__ctor(42) written above, executed here
         assert(i1 is null);
         assert(i2 !is null);
         i1 = new Inner;
     }
     this(int overloaded) {
         // i2 and i3 are constructed, same as above
     }
     ~this() {
         // implicit i2.__dtor();
         // implicit i3.__dtor();
         // i1 is still somewhere in the heap
     }
 }
 IN ENGLISH:
 If it's likely that class members will be constructed with and die with the

and cache misses. I was honesetly flabberghasted when I realized there was no way to do this in D, it seems like it should be one of the most basic constructs of a C-derived (or any low-ish level) language.
 The programmer knows best where he wants his objects stored. Also, the 'scope'

bodies. But the whole point of classes is that they're supposed to be polymorphic. If you don't need polymorphism, that's what structs are for. You can store them either inline (default) or in separate heap space (using pointers). If you do need polymorphism, you don't know at compile time what the size of the object is supposed to be, and initializing the object the way you suggest defeats polymorphism.
Mar 06 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
dsimcha wrote:
 But the whole point of classes is that they're supposed to be polymorphic.  If
you
 don't need polymorphism, that's what structs are for.  You can store them
either
 inline (default) or in separate heap space (using pointers).  If you do need
 polymorphism, you don't know at compile time what the size of the object is
 supposed to be, and initializing the object the way you suggest defeats
polymorphism.

scope can't use polymorphism. It's for situations in which you need your polymorphic type to be on the stack for whatever reason, but you don't need polymorphism at the moment. For example, you want to open a file. File inherits from some sort of Stream class; it's not a struct. So you can write: auto file = new File(path); scope(exit) file.close; Or: scope file = new File(path);
Mar 07 2009
parent reply John Simon <zildjohn01 gmail.com> writes:
Christopher Wright Wrote:

 dsimcha wrote:
 But the whole point of classes is that they're supposed to be polymorphic.  If
you
 don't need polymorphism, that's what structs are for.  You can store them
either
 inline (default) or in separate heap space (using pointers).  If you do need
 polymorphism, you don't know at compile time what the size of the object is
 supposed to be, and initializing the object the way you suggest defeats
polymorphism.

scope can't use polymorphism. It's for situations in which you need your polymorphic type to be on the stack for whatever reason, but you don't need polymorphism at the moment. For example, you want to open a file. File inherits from some sort of Stream class; it's not a struct. So you can write: auto file = new File(path); scope(exit) file.close; Or: scope file = new File(path);

Exactly. And on top of that, how does being 'scope' limit its polymorphism? Code time: int main(char[][] args) { class A {} class B : A {} class C : B {} void tryB(A a) {writefln(cast(B)a ? "casted" : "null");} scope a = new A; scope b = new B; assert(cast(C)b is null); // OK assert(cast(A)b == b); // OK tryB(a); // "null" tryB(b); // "casted" return 42; } You can always upcast and downcast safely, since it isn't actually a 'value' type, only the address is passed around. The type of the class remains intact. So I don't see why this shouldn't be extended to classes as aggregate members.
Mar 07 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
John Simon wrote:
 You can always upcast and downcast safely, since it isn't actually a 'value'
type, only the address is passed around. The type of the class remains intact.

Right, but a scope variable has its type decided at compile time, always. In that way, it's not polymorphic.
Mar 07 2009
parent John Simon <zildjohn01 gmail.com> writes:
Christopher Wright Wrote:

 John Simon wrote:
 You can always upcast and downcast safely, since it isn't actually a 'value'
type, only the address is passed around. The type of the class remains intact.

Right, but a scope variable has its type decided at compile time, always. In that way, it's not polymorphic.

True. But as long as you can still pass its reference around and have it behave correctly, I don't see how that's an issue.
Mar 07 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an aggregate body.
 
 Members of class type declared with the scope keyword are allocated not as
references or pointers, but initialized directly inside the container.  Instead
of a default initializer of 'null', it will initialize with the default
constructor of the class, or an optional assignment after the declaration. Any
'new [type]' within the assignment will resolve to a simple call to the type's
__ctor, instead of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.
Mar 07 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Sean Kelly wrote:
 John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an 
 aggregate body.

 Members of class type declared with the scope keyword are allocated 
 not as references or pointers, but initialized directly inside the 
 container.  Instead of a default initializer of 'null', it will 
 initialize with the default constructor of the class, or an optional 
 assignment after the declaration. Any 'new [type]' within the 
 assignment will resolve to a simple call to the type's __ctor, instead 
 of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.

Oh, I should mention that I'm not sure how the compiler would handle this scenario: class A { byte[16]; } class B { byte[32]; } class C { this( bool b ) { if( b ) o = new A; else o = new B; } scope Object o; } If I had to guess I'd say that the compiler would either reserve the max size necessary to store both A or B, or that in non-trivial cases it just wouldn't bother with reserving space for o at all.
Mar 07 2009
parent reply John Simon <zildjohn01 gmail.com> writes:
Sean Kelly Wrote:

 Sean Kelly wrote:
 John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an 
 aggregate body.

 Members of class type declared with the scope keyword are allocated 
 not as references or pointers, but initialized directly inside the 
 container.  Instead of a default initializer of 'null', it will 
 initialize with the default constructor of the class, or an optional 
 assignment after the declaration. Any 'new [type]' within the 
 assignment will resolve to a simple call to the type's __ctor, instead 
 of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.

Oh, I should mention that I'm not sure how the compiler would handle this scenario: class A { byte[16]; } class B { byte[32]; } class C { this( bool b ) { if( b ) o = new A; else o = new B; } scope Object o; } If I had to guess I'd say that the compiler would either reserve the max size necessary to store both A or B, or that in non-trivial cases it just wouldn't bother with reserving space for o at all.

Wrong. The Object is constructed when it comes into scope, and destructed when it leaves scope. Classes can't have an 'opAssign', instead the reference is reassigned. Since the reference is invariant/immutable here, this throws a compile time error. In C++ it's equivalent to: class Object{void *classInfo; ...}; class A : Object {}; void normalDClass() { Object *o; o = new A(); // OK! o = new B(); // OK! } void scopeDClass() { Object o; // initialized when entering function o = A(); // usually calls operator=(A &), i.e. opAssign(A &). // This is forbidden in D since A& is implicitly converible to Object. // Therefore a compile time error happens. // also, o is destructed here } The existing rules would work very well. The only thing you need to be careful of, is not to pass the object to someone who will keep the reference around.
Mar 07 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would handle 
 this scenario:

 class A { byte[16]; }
 class B { byte[32]; }
 class C {
      this( bool b ) {
          if( b ) o = new A;
          else    o = new B;
      }
      scope Object o;
 }

 If I had to guess I'd say that the compiler would either reserve the max 
 size necessary to store both A or B, or that in non-trivial cases it 
 just wouldn't bother with reserving space for o at all.

Wrong. The Object is constructed when it comes into scope, and destructed when it leaves scope. Classes can't have an 'opAssign', instead the reference is reassigned. Since the reference is invariant/immutable here, this throws a compile time error.

I'm talking about a proposed new feature, not an existing one. Please take this example in context.
Mar 07 2009
parent reply John Simon <zildjohn01 gmail.com> writes:
Sean Kelly Wrote:

 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would handle 
 this scenario:

 class A { byte[16]; }
 class B { byte[32]; }
 class C {
      this( bool b ) {
          if( b ) o = new A;
          else    o = new B;
      }
      scope Object o;
 }

 If I had to guess I'd say that the compiler would either reserve the max 
 size necessary to store both A or B, or that in non-trivial cases it 
 just wouldn't bother with reserving space for o at all.

Wrong. The Object is constructed when it comes into scope, and destructed when it leaves scope. Classes can't have an 'opAssign', instead the reference is reassigned. Since the reference is invariant/immutable here, this throws a compile time error.

I'm talking about a proposed new feature, not an existing one. Please take this example in context.

Sorry man, I thought you were disputing with me. My apologies. Let me rephrase. I believe that 'scope' declared objects shouldn't allow an assignment of a derived type. Reasoning being that there wouldn't be enough stack space allocated for it. So in your example above, Object could only recieve a 'new Object', and nothing further down in the hierarchy.
Mar 08 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
John Simon wrote:
 Sean Kelly Wrote:
 
 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would handle 
 this scenario:

 class A { byte[16]; }
 class B { byte[32]; }
 class C {
      this( bool b ) {
          if( b ) o = new A;
          else    o = new B;
      }
      scope Object o;
 }

 If I had to guess I'd say that the compiler would either reserve the max 
 size necessary to store both A or B, or that in non-trivial cases it 
 just wouldn't bother with reserving space for o at all.


take this example in context.

Sorry man, I thought you were disputing with me. My apologies. Let me rephrase. I believe that 'scope' declared objects shouldn't allow an assignment of a derived type. Reasoning being that there wouldn't be enough stack space allocated for it. So in your example above, Object could only recieve a 'new Object', and nothing further down in the hierarchy.

Ah, that makes sense. And it's an easy rule to follow.
Mar 08 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Mar 9, 2009 at 7:12 AM, John Simon <zildjohn01 gmail.com> wrote:
 Sean Kelly Wrote:

 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would handle
 this scenario:

 class A { byte[16]; }
 class B { byte[32]; }
 class C {
      this( bool b ) {
          if( b ) o = new A;
          else    o = new B;
      }
      scope Object o;
 }

 If I had to guess I'd say that the compiler would either reserve the max
 size necessary to store both A or B, or that in non-trivial cases it
 just wouldn't bother with reserving space for o at all.


take this example in context.

I believe that 'scope' declared objects shouldn't allow an assignment of a derived type. Reasoning being that there wouldn't be enough stack space allocated for it.


 So in your example above, Object could only recieve a 'new Object', and
nothing further down in the hierarchy.

I'm pretty sure that assigning to a scope class on the stack is not done by copying the memory. I'm pretty sure what happens is basically something like follows. This scope statement: scope foo = new TheClass; Basically becomes this: static ubyte[sizeof_TheClass] _mem; auto foo = new(_mem.ptr) TheClass;

To that add: scope(exit) foo.~this(); I don't think there's a syntax for destructor invocation. Never liked scope that much. Extremely dangerous for such a cute syntax. Andrei
Mar 08 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 08 Mar 2009 16:06:56 -0700, Andrei Alexandrescu wrote:

 Bill Baxter wrote:
 On Mon, Mar 9, 2009 at 7:12 AM, John Simon <zildjohn01 gmail.com> wrote:
 Sean Kelly Wrote:

 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would handle
 this scenario:

 class A { byte[16]; }
 class B { byte[32]; }
 class C {
      this( bool b ) {
          if( b ) o = new A;
          else    o = new B;
      }
      scope Object o;
 }

 If I had to guess I'd say that the compiler would either reserve the max
 size necessary to store both A or B, or that in non-trivial cases it
 just wouldn't bother with reserving space for o at all.


take this example in context.

I believe that 'scope' declared objects shouldn't allow an assignment of a derived type. Reasoning being that there wouldn't be enough stack space allocated for it.


 So in your example above, Object could only recieve a 'new Object', and
nothing further down in the hierarchy.

I'm pretty sure that assigning to a scope class on the stack is not done by copying the memory. I'm pretty sure what happens is basically something like follows. This scope statement: scope foo = new TheClass; Basically becomes this: static ubyte[sizeof_TheClass] _mem; auto foo = new(_mem.ptr) TheClass;

To that add: scope(exit) foo.~this(); I don't think there's a syntax for destructor invocation. Never liked scope that much. Extremely dangerous for such a cute syntax.

Shouldn't it be sort of scope(exit) (cast(TheClass)_mem.ptr).~this(); since foo may be re-assigned to something absolutely different?
Mar 08 2009
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 09/03/2009 00:12, John Simon wrote:
 Sean Kelly Wrote:

 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would
 handle this scenario:

 class A { byte[16]; } class B { byte[32]; } class C { this(
 bool b ) { if( b ) o = new A; else    o = new B; } scope Object
 o; }

 If I had to guess I'd say that the compiler would either
 reserve the max size necessary to store both A or B, or that in
 non-trivial cases it just wouldn't bother with reserving space
 for o at all.

destructed when it leaves scope. Classes can't have an 'opAssign', instead the reference is reassigned. Since the reference is invariant/immutable here, this throws a compile time error.

Please take this example in context.

Sorry man, I thought you were disputing with me. My apologies. Let me rephrase. I believe that 'scope' declared objects shouldn't allow an assignment of a derived type. Reasoning being that there wouldn't be enough stack space allocated for it. So in your example above, Object could only recieve a 'new Object', and nothing further down in the hierarchy.

how can the compiler enforce such a rule? class A { byte[16]; } class B : A { byte[32]; } class C { this(A a) { obj = a; } scope A obj; }
Mar 08 2009
parent John Simon <zildjohn01 gmail.com> writes:
Yigal Chripun Wrote:

 On 09/03/2009 00:12, John Simon wrote:
 Sean Kelly Wrote:

 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would
 handle this scenario:

 class A { byte[16]; } class B { byte[32]; } class C { this(
 bool b ) { if( b ) o = new A; else    o = new B; } scope Object
 o; }

 If I had to guess I'd say that the compiler would either
 reserve the max size necessary to store both A or B, or that in
 non-trivial cases it just wouldn't bother with reserving space
 for o at all.

destructed when it leaves scope. Classes can't have an 'opAssign', instead the reference is reassigned. Since the reference is invariant/immutable here, this throws a compile time error.

Please take this example in context.

Sorry man, I thought you were disputing with me. My apologies. Let me rephrase. I believe that 'scope' declared objects shouldn't allow an assignment of a derived type. Reasoning being that there wouldn't be enough stack space allocated for it. So in your example above, Object could only recieve a 'new Object', and nothing further down in the hierarchy.

how can the compiler enforce such a rule? class A { byte[16]; } class B : A { byte[32]; } class C { this(A a) { obj = a; } scope A obj; }

My proposal was to make scope object construction and destruction automatic and implicit, meaning any assignment would be illegal, besides an inline construction by the definition of the same type as the scope variable. However even if that restriction wasn't there, the runtime could restrict it the same way it does dynamic casting. I see no point to doing it this second way though.
Mar 09 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:
 John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an 
 aggregate body.

 Members of class type declared with the scope keyword are allocated 
 not as references or pointers, but initialized directly inside the 
 container.  Instead of a default initializer of 'null', it will 
 initialize with the default constructor of the class, or an optional 
 assignment after the declaration. Any 'new [type]' within the 
 assignment will resolve to a simple call to the type's __ctor, instead 
 of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.

I'd be happier if we investigated scope in classes as an ownership mechanism. In-situ storage is nice, but ownership management is more important. Andrei
Mar 07 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:
 Sean Kelly wrote:
 John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an 
 aggregate body.

 Members of class type declared with the scope keyword are allocated 
 not as references or pointers, but initialized directly inside the 
 container.  Instead of a default initializer of 'null', it will 
 initialize with the default constructor of the class, or an optional 
 assignment after the declaration. Any 'new [type]' within the 
 assignment will resolve to a simple call to the type's __ctor, 
 instead of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.

I'd be happier if we investigated scope in classes as an ownership mechanism. In-situ storage is nice, but ownership management is more important.

Yeah, in-situ storage would just be a QOI feature like it is for scope variables at function level. I agree that the logical effect of scope at class level is more important.
Mar 07 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Sean Kelly wrote:
 Andrei Alexandrescu wrote:
 Sean Kelly wrote:
 John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an 
 aggregate body.

 Members of class type declared with the scope keyword are allocated 
 not as references or pointers, but initialized directly inside the 
 container.  Instead of a default initializer of 'null', it will 
 initialize with the default constructor of the class, or an optional 
 assignment after the declaration. Any 'new [type]' within the 
 assignment will resolve to a simple call to the type's __ctor, 
 instead of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.

I'd be happier if we investigated scope in classes as an ownership mechanism. In-situ storage is nice, but ownership management is more important.

Yeah, in-situ storage would just be a QOI feature like it is for scope variables at function level. I agree that the logical effect of scope at class level is more important.

You're talking about something like this? class A { scope Object o; this () { o = new Object; } } converts to: class A { Object o; this () { void* ptr = gc.allocAndIgnore(Object.classinfo.size); o = new(ptr) Object; } ~this () { delete o; } }
Mar 07 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Christopher Wright wrote:
 Sean Kelly wrote:
 Andrei Alexandrescu wrote:
 Sean Kelly wrote:
 John Simon wrote:
 I'd like to propose a new use for the 'scope' keyword within an 
 aggregate body.

 Members of class type declared with the scope keyword are allocated 
 not as references or pointers, but initialized directly inside the 
 container.  Instead of a default initializer of 'null', it will 
 initialize with the default constructor of the class, or an 
 optional assignment after the declaration. Any 'new [type]' within 
 the assignment will resolve to a simple call to the type's __ctor, 
 instead of a memory allocation.

A while back, Walter said that he planned to do exactly this. I'm not sure what the timetable is though, or if plans have changed.

I'd be happier if we investigated scope in classes as an ownership mechanism. In-situ storage is nice, but ownership management is more important.

Yeah, in-situ storage would just be a QOI feature like it is for scope variables at function level. I agree that the logical effect of scope at class level is more important.

You're talking about something like this? class A { scope Object o; this () { o = new Object; } } converts to: class A { Object o; this () { void* ptr = gc.allocAndIgnore(Object.classinfo.size); o = new(ptr) Object; } ~this () { delete o; } }

For the logical aspect of scope variables, I was thinking more about possibly restricting whether they are allowed to escape from the scope in which they are declared, etc. The QOI feature would be to make the related allocations occur within the enclosing scope. So, for example: class C { byte[16] x; } Object fn() { scope C var = new C; // allocated on the stack return var; // possibly flagged as an error by the compiler } class D { scope C var; this() { var = new C; // in-place constructed within D } C get() { return var; // possibly flagged as an error } }
Mar 08 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Mar 9, 2009 at 7:12 AM, John Simon <zildjohn01 gmail.com> wrote:
 Sean Kelly Wrote:

 John Simon wrote:
 Sean Kelly Wrote:
 Oh, I should mention that I'm not sure how the compiler would handle
 this scenario:

 class A { byte[16]; }
 class B { byte[32]; }
 class C {
 =A0 =A0 =A0this( bool b ) {
 =A0 =A0 =A0 =A0 =A0if( b ) o =3D new A;
 =A0 =A0 =A0 =A0 =A0else =A0 =A0o =3D new B;
 =A0 =A0 =A0}
 =A0 =A0 =A0scope Object o;
 }

 If I had to guess I'd say that the compiler would either reserve the =




 size necessary to store both A or B, or that in non-trivial cases it
 just wouldn't bother with reserving space for o at all.

Wrong. The Object is constructed when it comes into scope, and destruc=



erence is reassigned. Since the reference is invariant/immutable here, this= throws a compile time error.
 I'm talking about a proposed new feature, not an existing one. =A0Please
 take this example in context.

Sorry man, I thought you were disputing with me. My apologies. Let me rep=

 I believe that 'scope' declared objects shouldn't allow an assignment of =

llocated for it.
 So in your example above, Object could only recieve a 'new Object', and n=

I'm pretty sure that assigning to a scope class on the stack is not done by copying the memory. I'm pretty sure what happens is basically something like follows. This scope statement: scope foo =3D new TheClass; Basically becomes this: static ubyte[sizeof_TheClass] _mem; auto foo =3D new(_mem.ptr) TheClass; Where new(addr) indicates a "placement new". So the memory for the initial instance is allocated on the stack, yes, but other than that foo act just like any other class pointer. In particular if you say foo=3Dotherfoo; you're just reassigning the pointer, not actually doing anything with the object allocated on the stack. It just becomes unreferenced junk. And before Walter says it -- I know, I should use obj2asm and look at the assembly to see for sure. --bb
Mar 08 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 07 Mar 2009 08:15:59 +0300, John Simon <zildjohn01 gmail.com> wrote:

 I'd like to propose a new use for the 'scope' keyword within an  
 aggregate body.

 Members of class type declared with the scope keyword are allocated not  
 as references or pointers, but initialized directly inside the  
 container.  Instead of a default initializer of 'null', it will  
 initialize with the default constructor of the class, or an optional  
 assignment after the declaration. Any 'new [type]' within the assignment  
 will resolve to a simple call to the type's __ctor, instead of a memory  
 allocation.

 Example:

 class Inner {
     this() {}
     this(int x) {}
 }

 class Container {
     Inner i1; // initialized to null
     scope Inner i2; // allocated within class
     scope i3 = new Inner(42); // allocated within class

     this() {
         // implicit i2.__ctor();
         // i3.__ctor(42) written above, executed here
         assert(i1 is null);
         assert(i2 !is null);
         i1 = new Inner;
     }

     this(int overloaded) {
         // i2 and i3 are constructed, same as above
     }

     ~this() {
         // implicit i2.__dtor();
         // implicit i3.__dtor();
         // i1 is still somewhere in the heap
     }
 }

 IN ENGLISH:

 If it's likely that class members will be constructed with and die with  
 the object, why not just allocate them right in the class? Save on heap  
 fragmentation and cache misses.  I was honesetly flabberghasted when I  
 realized there was no way to do this in D, it seems like it should be  
 one of the most basic constructs of a C-derived (or any low-ish level)  
 language.

 The programmer knows best where he wants his objects stored. Also, the  
 'scope' makes sense, and we should mirror the current behavior of the  
 keyword in function bodies.

I belive it could be implemented in a library. Something like this (not tested): struct Scope(T) { static assert(is(T : class)); private ubyte[SizeOf!(T)] _data = T.init[]; private bool _isConstructed = false; T value() { return cast(T)_data.ptr; } alias this value; void construct(Params...)(Params params) // perhaps, could be 'this' { assert(!_isConstructed); value.ctor(params); _isConstructed = true; } } Usage: class Foo { this(int i) { this.i = i; } int i; void doSomething() { } } class Bar { Scope!(Foo) foo; this() { // optional: foo.construct(42); // different syntax is also possible // same as foo = new Foo(42); Foo f = foo; // implicit cast foo.doSomething(); int i = foo.i; } }
Mar 08 2009
parent reply John Simon <zildjohn01 gmail.com> writes:
Denis Koroskin Wrote:

 On Sat, 07 Mar 2009 08:15:59 +0300, John Simon <zildjohn01 gmail.com> wrote:
 
 I'd like to propose a new use for the 'scope' keyword within an  
 aggregate body.

 Members of class type declared with the scope keyword are allocated not  
 as references or pointers, but initialized directly inside the  
 container.  Instead of a default initializer of 'null', it will  
 initialize with the default constructor of the class, or an optional  
 assignment after the declaration. Any 'new [type]' within the assignment  
 will resolve to a simple call to the type's __ctor, instead of a memory  
 allocation.

 Example:

 class Inner {
     this() {}
     this(int x) {}
 }

 class Container {
     Inner i1; // initialized to null
     scope Inner i2; // allocated within class
     scope i3 = new Inner(42); // allocated within class

     this() {
         // implicit i2.__ctor();
         // i3.__ctor(42) written above, executed here
         assert(i1 is null);
         assert(i2 !is null);
         i1 = new Inner;
     }

     this(int overloaded) {
         // i2 and i3 are constructed, same as above
     }

     ~this() {
         // implicit i2.__dtor();
         // implicit i3.__dtor();
         // i1 is still somewhere in the heap
     }
 }

 IN ENGLISH:

 If it's likely that class members will be constructed with and die with  
 the object, why not just allocate them right in the class? Save on heap  
 fragmentation and cache misses.  I was honesetly flabberghasted when I  
 realized there was no way to do this in D, it seems like it should be  
 one of the most basic constructs of a C-derived (or any low-ish level)  
 language.

 The programmer knows best where he wants his objects stored. Also, the  
 'scope' makes sense, and we should mirror the current behavior of the  
 keyword in function bodies.

I belive it could be implemented in a library. Something like this (not tested): struct Scope(T) { static assert(is(T : class)); private ubyte[SizeOf!(T)] _data = T.init[]; private bool _isConstructed = false; T value() { return cast(T)_data.ptr; } alias this value; void construct(Params...)(Params params) // perhaps, could be 'this' { assert(!_isConstructed); value.ctor(params); _isConstructed = true; } } Usage: class Foo { this(int i) { this.i = i; } int i; void doSomething() { } } class Bar { Scope!(Foo) foo; this() { // optional: foo.construct(42); // different syntax is also possible // same as foo = new Foo(42); Foo f = foo; // implicit cast foo.doSomething(); int i = foo.i; } }

Oh man I've tried, believe me. I couldn't figure out how to call the destructors in-place. Also, structs can't have parameter-less constructors
Mar 09 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
John Simon wrote:
 
 Oh man I've tried, believe me.
 I couldn't figure out how to call the destructors in-place. Also, structs
can't have parameter-less constructors

Have you tried just calling delete on the reference? That should do what you want. In D2 it certainly will at any rate... I haven't looked at the D1 lib source in a while.
Mar 09 2009
parent John Simon <zildjohn01 gmail.com> writes:
Sean Kelly Wrote:

 John Simon wrote:
 
 Oh man I've tried, believe me.
 I couldn't figure out how to call the destructors in-place. Also, structs
can't have parameter-less constructors

Have you tried just calling delete on the reference? That should do what you want. In D2 it certainly will at any rate... I haven't looked at the D1 lib source in a while.

That would call __dtor, but wouldn't it also screw up the garbage collector or allocator? Since the bytes would be located at offset 0 in the struct, wouldn't it try to free the same memory twice? Also I'm guessing there's no viable solution to the constructor problem, besides a mandatory member function. Which kills a lot of the elegance this type of construct would create
Mar 11 2009