On 10/2/2012 4:32, Warp wrote:
> "Scope" is defined by the stack.

Only for auto variables, yes.

> An object created inside a scope goes out
> of scope when that scope ends, of course.

Objects (i.e., values) don't have scopes. Variables have scopes. A scope is 
the portion of the program code over which the name of a variable is valid.

An object doesn't go out of scope when the scope ends. The variable 
referencing the object goes out of scope when the scope ends.

> If you create an object
> dynamically, it can outlive the scope where it was created.

And that's the problem.

> 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.

And that too is the problem.

>> 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.

Well, you asked me why the compiler couldn't just add the destructor for 
you. This is your answer: it's rather obvious.

>>> (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.

So if I want to pass an object into a function as an argument, and then 
still use it when that function returns, I can't?

Also, how does the compiler know you've moved it, so you *don't* reference 
it upon return?

>>> (The reason is that it uses move semantics rather than copy semantics.)
>
>> But nothing enforces that.
>
> The class itself can enforce it.

"Can enforce" is not the same as "enforce".  it's not part of the semantics 
of the language.

>>>> 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?

No. That's exactly the point of the declarations like [claim] that I showed 
you. You can't dereference it after it's destroyed because the declarations 
prevent you from dereferencing it after someone else has claimed it, and 
destroying it claims it.


-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message