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.mikaels...@gmail.com> wrote: > 2011/1/3 Iain Buclaw <ibuc...@ubuntu.com>: >> == Quote from bearophile (bearophileh...@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.
