why allocators are not discussed here

Dmitry Olshansky dmitry.olsh at gmail.com
Wed Jun 26 12:39:21 PDT 2013


26-Jun-2013 23:04, cybervadim пишет:
> On Wednesday, 26 June 2013 at 14:59:41 UTC, Dmitry Olshansky wrote:

>> 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.

I know what kind of thing you are talking about. It's ain't powerful 
it's just a hack that doesn't quite do what advertised.

> This is unsafe, but if you want it safe, don't use allocators, stay with
> GC.

BTW you were talking changing allocation of the code you didn't write.
There is not even single fact that makes the thing safe. It's all 
working by chance or because the thing was designed to work with scoped 
allocator to begin with.

I believe the 2nd case (design to use scoped allocation) is
a) The behavior is guaranteed (determinism vs GC etc)
b) Safety is assured be the designer not pure luck (and reasonable 
assumption that may not hold)

> 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.

Yeah I know, hence I showed it. BTW forget about malloc I'm not talking 
about explicit malloc being an alternative to you scheme.

 > The fact that you may write bad code does not make the language (or
 > concept) bad.

It does. Because it introduces easy unreliable and bug prone usage.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list