why allocators are not discussed here

[Dmitry Olshansky]

26-Jun-2013 03:16, Adam D. Ruppe пишет:
> On Tuesday, 25 June 2013 at 22:50:55 UTC, H. S. Teoh wrote:
>> And maybe (b) can be implemented by making gc_alloc / gc_free
>> overridable function pointers? Then we can override their values and
>> use scope guards to revert them back to the values they were before.
>
> Yea, I was thinking this might be a way to go. You'd have a global
> (well, thread-local) allocator instance that can be set and reset
> through stack calls.
>
> You'd want it to be RAII or delegate based, so the scope is clear.
>
> with_allocator(my_alloc, {
>       do whatever here
> });
>
>
> or
>
> {
>     ChangeAllocator!my_alloc dummy;
>
>     do whatever here
> } // dummy's destructor ends the allocator scope
>

Both suffer from
a) being totally unsafe and in fact bug prone since all references 
obtained in there are now dangling (and there is no indication where 
they came from)
b) imagine you need to use an allocator for a stateful object. Say 
forward range of some other ranges (e.g. std.regex) both scoped/stacked 
to allocate its internal stuff. 2nd one may handle it but not the 1st one.
c) transfer of objects allocated differently up the call graph (scope 
graph?), is pretty much neglected I see.

I kind of wondering how our knowledgeable community has come to this.
(must have been starving w/o allocators way too long)

> {
>     malloced_string str;
>     auto got = to!string(10, str);
> } // str is out of scope, so it gets free()'d. unsafe though: if you
> stored a copy of got somewhere, it is now a pointer to freed memory. I'd
> kinda like language support of some sort to help mitigate that though,
> like being a borrowed pointer that isn't allowed to be stored, but
> that's another discussion.
>
In contrast 'container as an output range' works both safely and would 
be still customizable.

IMHO the only place for allocators is in containers other kinds of code 
may just ignore allocators completely.

std.algorithm and friends should imho be customized on 2 things only:

a) containers to use (instead of array)
b) optionally a memory source (or allocator) f container is 
temporary(scoped) to tie its life-time to smth.

Want temporary stuff? Use temporary arrays, hashmaps and whatnot i.e. 
types tailored for a particular use case (e.g. with a temporary/scoped 
allocator in mind).
These would all be unsafe though. Alternative is ref-counting pointers 
to an allocator. With word on street about ARC it could be nice 
direction to pursue.

Allocators (as Andrei points out in his video) have many kinds:
a) persistence: infinite, manual, scoped
b) size: unlimited vs fixed
c) block-size: any, fixed, or *any* up to some maximum size

Most of these ARE NOT interchangeable!
Yet some are composable however I'd argue that allocators are not 
composable but have some reusable parts that in turn are composable.

Code would have to cutter for specific flavors of allocators still so 
we'd better reduce this problem to the selection of containers.

-- 
Dmitry Olshansky