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
