GC-less tutorial?

[Tove]

On Saturday, 7 April 2012 at 17:31:02 UTC, Artur Skawina wrote:
> On 04/07/12 17:25, Tove wrote:
>> Hi,
>> 
>> are there any good tutorials for using D totally without GC, 
>> detailing some common pitfalls?
>> 
>> One thing on my wishlist would be a way to detect accidental 
>> GC allocations resulting from side-effects of every-day 
>> operations... generating linking errors would be sufficient 
>> for detecting this...
>
> One problem with this is that the runtime wants to alloc some 
> things before your
> code gets to run - so you can't just remove the functions from 
> the build. You're
> left with either modifying the runtime or somehow ignoring the 
> initial allocations
> (which usually won't cause any problems). If using a custom RT 
> would have been an
> option you wouldn't be asking these questions (as you could 
> just omit the symbols),
> so...
>
> If your platform supports gdb, try creating a text file 
> "trapallocs" containing:
>
> b gc_malloc
> b gc_qalloc
> b gc_calloc
> b gc_realloc
> b gc_extend
>
> then run "gdb -x ./trapallocs -ex run --args ./your_app"
>
> The debugger will stop at the first allocation and you can then 
> use "bt"
> to check what's going on, then "c" to skip to the next alloc. 
> The first few
> will come from the runtime and various module ctors, but 
> anything after
> that will be caused by your code, directly or indirectly.
>
> You can also trap just the array ops with eg:
>
> b _d_arraycatT
> b _d_arraycatnT
> b _d_arrayappendT
> b _d_arrayappendcTp
> b _d_newarrayT
>
> etc
>
> Once the runtime becomes a shared library simpler solutions 
> will be possible,
> but, until then, it doesn't get much better than this. You need 
> some way to
> determine which allocations are "legal" and which are not; 
> doing this w/o
> a custom runtime is probably not worth the effort...
>
> And, yes, the initial runtime allocations could (and should) me 
> made to use a
> different path; some of them shouldn't happen at all. For 
> example std.datetime
> alone causes two allocs via _d_newclass, in every D app that 
> imports std.stdio...
>
>
> artur

great, thanks for the hint, I didn't think of using breakpoints 
at first... but you are right, given good enough unit tests, the 
coverage would be sufficient!