D without a GC

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Jan 4 03:33:15 PST 2011


On 04.01.2011 6:42, Christopher Bergqvist wrote:
> 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.
First of all it's main purpose was allocating class instances on stack.
Second the way it's implemented the size should be known at compile-time.
And yes, it's still somewhat experimental and has some issues.

As for stackAllocate!(T)(n). It should be mixin, since function can't 
return it's alloca'ed blocks, plus this allows all forms of clean up to 
be embedded in the same mixin with scope(exit){ __dtor(...);  }
> 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.


-- 
Dmitry Olshansky



More information about the Digitalmars-d mailing list