On Friday, 25 October 2013 at 17:57:23 UTC, Dmitry Olshansky wrote:
> Very true. To put it simply it's a disastrous idea that sadly is too easy to be ignored.
>
> IMHO we'd better start with containers and refitting Phobos from built-in AA/arrays to user-defined containers. One interesting way there is to accept/adopt containers as OutputRange.

Typed allocator on top of this should be defined before this is discussed. Right it doesn't make a lot of sense.

25-Oct-2013 23:26, Namespace пишет:
> On Friday, 25 October 2013 at 19:03:14 UTC, Dmitry Olshansky wrote:
>>
>> O.T. I'd gladly kill built-in AA though just to save people a lot of
>> time spent on debugging that crap. More precisely I'd keep AA
>> _literals_ and give the user the means to construct any type of
>> Key-->Value store out of it. It's too late probably.
>
> With which syntax? As far as e.g. int[string] (and not something ugly as
> Map!(string, int)) would stay what would be the problem to change the
> backend?

Map!(string,int) is fine actually as I'm no syntax fan anyway.

It's not the problem with "backend" as much as with its state and the interface it imposes:

a) It's stuck in between compiler intrinsic and library artifact. Being neither it has weaknesses of both (well that's fixable).
b) Interface... I don't even know where to start. But first of all: it's a hash table and can't be anything else - see the rehash function. More interestingly it escapes pointers ('in' operator) that must stay valid until another insert. That's a tough constraint on hash table (HT) implementation. Being HT it doesn't expose nor allows to change the load-factor.
c) Built-in HTs are one size fits all. Needless to say - it doesn't always fit and in particular there are many variations that trade insert/remove and/or space-efficiency for faster lookup and vise-versa. Also to stay on topic - memory management / deterministic cleanup? Trivial in UDT but not in built-ins.
d) AA literals are of no use the moment one stops using built-in HTs least one constructs temporary built-in HTs on GC heap. In my opinion if that's left as is the AA literal feature doesn't quite pull its weight.

All in all built-in AA are aging badly since D1 days.

-- 
Dmitry Olshansky

25-Oct-2013 23:50, deadalnix пишет:
> On Friday, 25 October 2013 at 17:57:23 UTC, Dmitry Olshansky wrote:
>> Very true. To put it simply it's a disastrous idea that sadly is too
>> easy to be ignored.
>>
>> IMHO we'd better start with containers and refitting Phobos from
>> built-in AA/arrays to user-defined containers. One interesting way
>> there is to accept/adopt containers as OutputRange.
>
> Typed allocator on top of this should be defined before this is
> discussed. Right it doesn't make a lot of sense.

Yeah, that's another step before that.

It's just I'm strongly opposed to "the strap this magical new allocator somewhere so that's it's global for everything, right now" movement and I had to plot the alternative course ;)

-- 
Dmitry Olshansky

On 10/25/2013 05:21 PM, Andrei Alexandrescu wrote:
> On 10/25/13 5:50 AM, Timon Gehr wrote:
>> - Possible null dereference on line 3128. :o)
>>    (In general, CascadingAllocator is not yet very composable. It should
>> return null allocations instead of failing in undocumented ways.
>
> Good point. Fixed and pushed.
> ...

Thanks.

>> It
>> should probably also allow the 'make' function to return null.)
>
> make() returns Allocator objects by value, not pointers.
> ...

'Allocator' could in general be a reference type.

>> - "CAllocator". The name is non-descriptive/misleading.
>
> "Class Allocator" :o)
> ...

Then its purpose must be allocating classes? :o)

On 10/25/2013 08:50 PM, Michel Fortin wrote:
> On 2013-10-25 15:14:38 +0000, "Adam D. Ruppe"
> <destructionator@gmail.com> said:
>
>> @safe void setAllocator(Allocator)(pure @safe void function() code) {}
>>
>> just might work out.
>
> I wonder what kind of things can be done in a pure function that takes
> no parameter and returns void. Not much I guess.
>

It can e.g. allocate data and embed it in an exception. (Which is also why the above function is still unsafe.)

On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> I know it's been a long wait. Hopefully it was worth it. The alpha release of untyped allocators is ready for tire-kicking and a test drive.
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html

Not really qualified to comment, but looks cool.

Looking at AllocatorWithStats,

https://github.com/andralex/phobos/blob/allocator/std/allocator.d#L2913

it looks like an error, should be

... static if (flags & Options.callerTime)

Goughy

On 10/25/13 6:17 PM, goughy wrote:
> On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> I know it's been a long wait. Hopefully it was worth it. The alpha
>> release of untyped allocators is ready for tire-kicking and a test drive.
>>
>> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>>
>> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html
>
> Not really qualified to comment, but looks cool.
>
> Looking at AllocatorWithStats,
>
> https://github.com/andralex/phobos/blob/allocator/std/allocator.d#L2913
>
> it looks like an error, should be
>
> ... static if (flags & Options.callerTime)
>
> Goughy

Famous criminals Cut & Paste strike again. Thanks!

Andrei

On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> ... awesome stuff ...
>
> Please destroy! I've literally sweat as I'm sending this :o).
>
>
> Andrei

I like it a lot so far.

I was really worried about being able to dynamically dispatch to an allocator determined at a previous place in the call stack, and it seems you're all over it with CAllocator.  Hell yeah!

I have an editing suggestion for the CAllocator comment:
Instead of
"Implementation of CAllocator using Allocator. [...]"
I suggest
"Implements CAllocator using the given Allocator. [...]"
The current one read strangely to me at first, and I had to re-read it several times and notice that "Allocator" referred to the template parameter.

I agree with others that say that the name CAllocator is too ambiguous or vague.  When I scanned through the allocators, I initially dismissed it because I though it was a proxy for the system's underlying C allocator, with Mallocator being a D-based optimized reimplementation of the C allocator.  Reading further clarified this, but it does probably harm skimming and searching.

I suggest an alternative name for CAllocator: DispatchingAllocator.  I believe this may represent what it does: dispatch allocation to another allocator that is behind a curtain.  Something like AbstractAllocator might work too, but still seems slightly ambiguous to me (i.e. abstract in what sense?).

I just hope that the future "top" allocator that handles language-builtin allocations will be one that can maintain a stack of allocators and push/pop the current default allocator, as well as prevent or redirect allocator choice made within calls to 3rd party libraries (assuming the libraries are written in D, of course).

Am Sat, 26 Oct 2013 00:11:13 +0200
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> >> - "CAllocator". The name is non-descriptive/misleading.
> >
> > "Class Allocator" :o)
> > ...
> 
> Then its purpose must be allocating classes? :o)

I'm actually fine with that name, probably because I tend to prefix my D reference types in that manner, too. 'I' for interfaces, 'C' for classes and maybe 'A' for abstract classes.

-- 
Marco

On 2013-10-26 11:03, Marco Leise wrote:

> I'm actually fine with that name, probably because I tend to
> prefix my D reference types in that manner, too. 'I' for
> interfaces, 'C' for classes and maybe 'A' for abstract classes.

That's just horrible.

-- 
/Jacob Carlborg