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