Darren New <dne### [at] sanrrcom> wrote:
> On 10/1/2012 6:29, Warp wrote:
> > Darren New<dne### [at] sanrrcom>  wrote:
> >>> Since the compiler can track when the object goes out of scope,
> >
> >> But C++ can't do this
> >
> > Of course it can. That's the very essence of RAII.

> Only for stuff I allocate on the stack and which I don't pass by value.

"Scope" is defined by the stack. An object created inside a scope goes out
of scope when that scope ends, of course. If you create an object
dynamically, it can outlive the scope where it was created.

If you pass the object by value, you are creating a *new* object (with its
own scope). It's not the same object. That's what "copying" means.

> I'm not confusing them at all. I'm simply pointing out that scope-tracking 
> doesn't work for heap-allocated objects.

That's rather obvious, given that heap-allocated objects are not
scope-based.

> > (If you really need to pass such an object as a function parameter, then
> > you can do it by using *move* semantics rather than *copy* semantics.)

> And when you move it back...?

You don't "move it back". If you move a resource you relinquish it to
whatever you are moving it to.

> > (The reason is that it uses move semantics rather than copy semantics.)

> But nothing enforces that.

The class itself can enforce it.

> >> Singularity does it by making you declare the function like this:
> >> void xyz([claimed] tracked one, tracked two) { destroy one; }
> >> (or some such syntax)
> >
> > What exactly stops the compiler from generating the destructor call
> > automatically? Why exactly do you have to write it explicitly?

> Because you might want to destruct something somewhere other than when 
> returning from a block, I suppose.

And have the possibility of dereferencing a destroyed object?

-- 
                                                          - Warp

Post a reply to this message