why allocators are not discussed here

cybervadim vadim.goryunov at gmail.com
Wed Jun 26 12:04:02 PDT 2013


On Wednesday, 26 June 2013 at 14:59:41 UTC, Dmitry Olshansky 
wrote:
> Here is a chief problem - the assumption that is required to 
> make it magically work.
>
> Now what I see is:
>
> T arr[];//TLS
>
> //somewhere down the line
> arr = ... ;
> else{
> ...
> alloctor(myAlloc){
> 	arr = array(filter!....);
> }
> ...
> }
> return arr;
>
> Having an unsafe magic wand that may transmogrify some code to 
> switch allocation strategy I consider naive and dangerous.
>
> Who ever told you process does return before allocating a few 
> Gigs of RAM (and hoping on GC collection)? Right, nobody. Maybe 
> it's an event loop that may run forever.
>
> What is missing is that code up to date assumes new == GC and 
> works _like that_.

Not magic, but the tool which is quite powerful and thus it may 
shoot your leg.
This is unsafe, but if you want it safe, don't use allocators, 
stay with GC.
In the example above, you get first arr freed by GC, second arr 
may point to nothing if myAlloc was implemented to free it 
before. Or you may get a proper arr reference if myAlloc used 
malloc and didn't free it. The fact that you may write bad code 
does not make the language (or concept) bad.



More information about the Digitalmars-d mailing list