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