D without a GC

[Christopher Bergqvist]

Would std.typecons.scoped!(T) fit?

http://svn.dsource.org/projects/phobos/trunk/phobos/std/typecons.d

I can't figure out why it's not in the generated reference docs, but exists in the source. Maybe it hasn't been tested enough yet.

On 3 Jan 2011, at 15:33, Ulrik Mikaelsson <ulrik.mikaelsson at gmail.com> wrote:

> 2011/1/3 Iain Buclaw <ibuclaw at ubuntu.com>:
>> == Quote from bearophile (bearophileHUGS at lycos.com)'s article
>>> Dmitry Olshansky:
>>>> As stated in this proposal they are quite useless, e.g. they are easily
>>>> implemented via mixin with alloca.
>>> Thank you for your comments. Here I have added some answers to your comments:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=5348
>>> Bye,
>>> bearophile
>> 
>> Some thoughts to your proposal:
>> 
>>> void bar(int len) {
>>>     Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof);
>>>     if (ptr == null)
>>>         throw new Exception("alloca failed");
>>>     Foo[] arr = ptr[0 .. len];
>>>     foreach (ref item; arr)
>>>         item = Foo.init;
>>> 
>>>     // some code here
>>>     writeln(arr);
>>> 
>>>     foreach (ref item; arr)
>>>         item.__dtor();
>>> }
>> 
>> 1) Why call the dtors manually? Forgive me if I'm wrong, but iirc, alloca will
>> free the memory when the stack exits from the current frame level. :)
> The dtor doesn't free memory, it allows the class to perform cleanup
> on destruction, such as close():ing any native FD:s etc.
> 
> Actually, AFAICT, the above code should also after "item=Foo.init"
> call item.__ctor(), to allow the constructor to run.
> 
> IMHO, stdlibs should provide wrappers for this type of functionality.
> An application-writer should not have to know the intricate details of
> __ctor and __dtor as opposed to memory-mangement etc. A template
> "stackAllocate!(T)" would be nice.