std.typed_allocator: very very very primitive tracing example

[Orvid King via Digitalmars-d]

The only thing I could see being an issue is the size of resulting
scanning code, which could probably be mitigated by using a
`bitmap`-ish representation as a key, so that types that have the same
bitmap use the same scanning function. Also, I see a *very* large
number of indirect branching occurring with this design, so you might
as well account for a branch misprediction for each an every object of
a non-final class allocated, due to fields possibly storing classes
derived from the type of the field. This also begs the question, how
do you intend to account for references to objects allocated outside
of the scope of that particular typed allocator, which may, or may
not, have the function pointer for scanning them.

On 5/4/14, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/4/14, 9:26 PM, Andrei Alexandrescu wrote:
>> For those keeping score at home, I've just updated
>>
>> https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>> https://github.com/andralex/phobos/blob/allocator/std/typed_allocator.d
>
> Forgot to mention: this latest development seems to suggest that the
> UNTYPED part of the allocator is becoming somewhat feature stable, so
> it's approaching alpha state.
>
> What std.allocator (i.e. the untyped part) needs right now is a few
> "best of" prepackaged allocators that are known to work well and allow
> coders to simply use them as short types or function calls, without
> needing to go through the intricate process of designing
> application-specific allocators.
>
>
> Andrei
>
>
>