Is that possible?
I can initialize an object with scope or, in feature, with scoped, directly on the stack but is it also possible to move an existing object from the heap to the stack?

On Wednesday, 19 September 2012 at 13:32:42 UTC, Namespace wrote:
> Is that possible?
> I can initialize an object with scope or, in feature, with scoped, directly on the stack but is it also possible to move an existing object from the heap to the stack?

I tried this:
http://dpaste.dzfl.pl/2955ff41
But as you can see in line 25/26, after I destroyed the heap object, the stack object seems to be corrupted.

On Wed, 19 Sep 2012 15:45:21 +0200, Namespace <rswhite4@googlemail.com> wrote:

> On Wednesday, 19 September 2012 at 13:32:42 UTC, Namespace wrote:
>> Is that possible?
>> I can initialize an object with scope or, in feature, with scoped, directly on the stack but is it also possible to move an existing object from the heap to the stack?
>
> I tried this:
> http://dpaste.dzfl.pl/2955ff41
> But as you can see in line 25/26, after I destroyed the heap object, the stack object seems to be corrupted.

The problem here is that A.sizeof returns the size of the reference, not
the instance. Instead you should use __traits(classInstanceSize, A).

Also, do have a look at the internals of std.typecons.scoped, it likely
contains some good ideas.

-- 
Simen

Thanks, I will use __traits(classInstanceSize, A);
But it does not work either.

On Wednesday, 19 September 2012 at 14:16:31 UTC, Namespace wrote:
> Thanks, I will use __traits(classInstanceSize, A);
> But it does not work either.

This is because classes are already pointers. when you write "&a", you are getting the address of pointer itself. So when you memcopy, don't use "&a", but use "cast(void*)a".

What you were currently doing was memcopying the "pointer to a" into your chunk. From there, since you were casting to A*, everything worked and was legal, but you still only had 1 class intance. Your destroying that instance made your ap crash.

this works:
http://dpaste.dzfl.pl/8ba1f457

On Wednesday, 19 September 2012 at 17:08:28 UTC, monarch_dodra wrote:
> On Wednesday, 19 September 2012 at 14:16:31 UTC, Namespace wrote:
>> Thanks, I will use __traits(classInstanceSize, A);
>> But it does not work either.
>
> This is because classes are already pointers. when you write "&a", you are getting the address of pointer itself. So when you memcopy, don't use "&a", but use "cast(void*)a".
>
> What you were currently doing was memcopying the "pointer to a" into your chunk. From there, since you were casting to A*, everything worked and was legal, but you still only had 1 class intance. Your destroying that instance made your ap crash.
>
> this works:
> http://dpaste.dzfl.pl/8ba1f457

I forget this. Thank you!
IMO something like this should exist in phobos. A more flexible version of scoped also.

Result:
http://dpaste.dzfl.pl/24988d8f

On Wednesday, 19 September 2012 at 19:24:34 UTC, Namespace wrote:
> Result:
> http://dpaste.dzfl.pl/24988d8f

I like it, but how can something placed on the stack be reference counted? The "chunk" is also placed on the stack, so it doesn't really make sense to me: When the object goes out of scope, the chunk goes, regardless of ref count. I think you should ditch the whole ref count thing.

You'll also have to be aware of the dangers of putting a class instance on the stack:

main()
{
    A a;
    {
        stacked_obj!A so;
        so.gen;
        a = so.get;
    }
    a.print(); //<-- undefined, with or without reference count
}

IE: Big red comment you should NEVER extract an instance from the stack.

I count it to destroy it if it isn't used anymore.
I can remove this behaviour but IMO with this you haven't unnecessary use of stack memory. Am I wrong?
Furthermore, if I copy the stack object e.g. if I pass it as value parameter to another function/class, I can store it as long as it's needed. Maybe that should be the task of the heap, but I'm not sure.

On Wednesday, 19 September 2012 at 21:36:56 UTC, Namespace wrote:
> I count it to destroy it if it isn't used anymore.
What I'm saying though is that when your "stacked_obj" goes out of scope, it gets destroyed, 100% of the time. The "chunk" disappears, along with any object inside it. When that happens, it doesn't matter what the count is, whatever is inside chunk MUST be destroyed.

> I can remove this behaviour but IMO with this you haven't unnecessary use of stack memory. Am I wrong?
Yes, because all your stacked_obj have a chunk member variable. The reference count doesn't change that. When you pass by value, a new chunk is created an copied.

Your postblit is weird:
this(this) {
	this._use_counter++;
	this._use_counter = _use_counter;
}
The way postblit works is that first, the "other" is memcopyed onto this. Then, postblit modifies the current object. "this._use_counter = _use_counter;" makes no sense.

One more thing: You can't memcopy a class from one place to another, because you don't know if it has a CC or not. You *could* swap the class, which would be safe for the class itself, but not for anything else referencing the class.

> Furthermore, if I copy the stack object e.g. if I pass it as value parameter to another function/class, I can store it as long as it's needed. Maybe that should be the task of the heap, but I'm not sure.
Yes, but technically, you are still passing a copy.

Anyways, I re-read scoped's implementation, and classes ARE allocated on the stack. Further more, they can emplace their new object.

They can also copy an existing class into them... provided the class gives access to CC. It is not a move, but, IMO, a move would be unsafe anyways.

import std.typecons;

class A
{
    this(){}
    this(int){}
    this(A){}
}

void main()
{
    auto sa = scoped!A(new A());
    auto sb = scoped!A(5);
}

I'm not entirely.