Eliminate class allocators and deallocators?

[Leandro Lucarella]

Andrei Alexandrescu, el  7 de octubre a las 13:06 me escribiste:
> >I think is a good idea not to force the GC to free the memory immediately
> >with a delete, but it should if it's easy. Other protection methods as
> >using mprotect to protect the objects pages it's very desirable too,
> >because you can spot an access to a inconsistent (destroyed) object as
> >soon as it first happen.
> 
> (mprotect is much too coarse to be useful.) With the dispose()
> function the state of the object will be restored to default
> construction:
> 
> void dispose(T)(T obj) if (is(T == class) || is(typeof(*T.init))) {
>    ... call destructor if any ...
>    ... obliterate object with .init ...
>    ... invoke default ctor if any ...
> }

Ok, if you're going to name that dispose, is fine with me. End of
discussion. With the addition of calling a constructor after destroying
the object, make a little more sense too (I still find it too bug prone,
you can end up with corruption if you dispose an object that other part of
the program think it's not disposed yet, i.e., in a state different than
the recently constructed object).

> >If you want to introduce a new semantic, I think you should provide a new
> >method, not change the semantic of an existent one.
> 
> Agreed. I hereby vote for deprecating delete with extreme prejudice.
> 
> >And BTW, is there any reason why this can't be implemented in the library
> >instead of using an operator? Why don't you provide a "destroy()" function
> >for that in Phobos?
> 
> That sounds great.
> 
> >Really, I can't see any advantages on changing the delete operator
> >semantics, only problems.
> 
> I agree.

I'm glad to see that.

> >Why? Using malloc and free is a lot more trouble, you have to register the
> >roots yourself for example. It's not like you do malloc() and free() and
> >everything works magically. You have to have more knowledge of the GC to
> >use them. Being able to manually manage the *GC* heap (if the GC support
> >that, if not it can make it a NOP) is good IMHO.
> 
> We can make things a tad better with library functions, but we do
> need to have a garbage collected heap that guarantees safety.

I don't think I understand this very well. What kind of safety? If the
user disposed/freed an object before it should, it's an user bug, with
unavoidable bad side effects. The best you can do is make the program
blow in the user face ASAP.

I don't understand what all this have to do with GC safety.

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
It's not a lie, if you believe it.
	-- George Constanza