On 9/22/13 9:19 PM, Manu wrote:
> On 23 September 2013 13:01, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>     Containers and other objects that want to allow customization of
>     their allocation would be parameterized during compilation with an
>     allocator type. Functions that need to allocate memory may similarly
>     accept a parameter of allocator type.
>
> You've just described C++ verbatim.
> And you've previously agreed that C++'s approach totally failed. Can you
> explain how this is different from C++, and how it solves the issues
> that defeated that design?

As I just wrote in my previous post, the two mistakes in C++'s allocator design are:

1. Allocators are parameterized by type.

2. Allocators cannot have state.

I fix both.

>     One possibility I'm keeping in mind is that of defining a dynamic
>     interface (i.e. in the OOP sense) for a global allocator. Then
>     people can globally change what allocator must be used for operator
>     new invocations.
>
> Right, this is getting warmer. It's a stark contrast to what you suggest
> above though, and when I try and think this through, it gets very
> complex, very fast.
> I can't imagine how such a system could ever be declared safe. However,
> this is more or less what I want. I don't know how to reconcile the 2
> requirements.

There are possibilities, which I hope to get to soon.

> How much have you thought on this? This is where I think some serious
> creativity will need to be applied...
>
> Following this train of thought, I can imagine a really nice end goal
> would be that the existing GC is effectively plugged in as a library,
> and people can easily substitute it for their own GC if they want/need to.

Sean has already done that. The current GC is entirely replaceable (and in particular extricable).


Andrei

On 9/22/13 10:20 PM, Benjamin Thaut wrote:
> Am 23.09.2013 01:49, schrieb Andrei Alexandrescu:
>> Hello,
>>
>>
>> 2. Untyped allocator - traffics exclusively in ubyte[].
>>
>
> Why "ubyte[]" and not "void[]"?

It's the logical choice at this level.

ubyte[] == "these are octets"


Andrei

On 9/22/13 10:37 PM, Walter Bright wrote:
> On 9/22/2013 9:19 PM, Manu wrote:
>> Following this train of thought, I can imagine a really nice end goal
>> would be
>> that the existing GC is effectively plugged in as a library, and
>> people can
>> easily substitute it for their own GC if they want/need to.
>
> It already is, and has been from the beginning. Rainer, for example,
> uses a different GC for VisualD.

Correct.

> dmd knows naught about the GC.

Well except for plugging a library call for calls to new. But that's expected.

(I'm already pretending delete doesn't exist :o).)


Andrei

On 23 September 2013 23:38, Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-23 11:31, qznc wrote:
>
>  5. Class local - The allocator is used for specific types (e.g. ASTNode
>> in a compiler)
>>
>> 6. Class-hierarchy - The allocator is used for a specific type hierarchy (e.g. ASTNode might have sub classes Statement,BinOp,etc)
>>
>> 7. Container local - The C++ way which binds allocation to a wrapping container
>>
>> 8. Task local - like Thread local but for std.parallelism.Task
>>
>> That's it for now.
>>
>> This is quite a long list, which means it is probably exhaustive. There should be a generic approach which encompasses at least those cases.
>>
>
> That's a good addition to the list.


Another situation that I've encountered on a few occasions...
Imagine I declare a particular allocator for my application, when dealing
with 3rd party libs, I expect it to allocate within my application's heap.
Seems like a situation where I might set a global allocator...
Mr 3rd party library also has its own allocators though, things like pools
or groups which it uses explicitly within it's code.
I don't actually want to override these allocators, since they're
effectively a higher-level construct, but I *do* want to override these
allocator's memory source. Ie, they should allocate their pools from my
application's heap, rather than the default heap.
So in this way, it's important to be able to set overrides at multiple
levels.

On 24 September 2013 00:04, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 9/22/13 10:20 PM, Benjamin Thaut wrote:
>
>> Am 23.09.2013 01:49, schrieb Andrei Alexandrescu:
>>
>>> Hello,
>>>
>>>
>>> 2. Untyped allocator - traffics exclusively in ubyte[].
>>>
>>>
>> Why "ubyte[]" and not "void[]"?
>>
>
> It's the logical choice at this level.
>
> ubyte[] == "these are octets"


Isn't that what void[] also means?
Except it says "these are un-typed octets, ie, not a sequence of typed
integers in the range 0-255".

On 9/23/13 12:31 AM, Jacob Carlborg wrote:
> On 2013-09-23 01:49, Andrei Alexandrescu wrote:
>
>> I am making good progress on the design of std.allocator, and I am
>> optimistic about the way it turns out. D's introspection capabilities
>> really shine through, and in places the design does feel really
>> archetypal - e.g. "this is the essence of a freelist allocator". It's a
>> very good feeling. The overall inspiration comes from Berger's
>> HeapLayers, but D's introspection takes that pattern to a whole new
>> level.
>
> I agree with Manu here. I thought the whole point was to come up with a
> design and API how the allocators are supposed to be used. How they
> integrate with user code.

This is a disconnect. I say "Well, I'm exploring car engines and this Otto cycle looks promising, here's how a transmission would work, and the brake system would be hydraulic..." and you say "but I want to know how to drive a car, and road regulations, and laws!"

Both are important, but they are very difficult to handle simultaneously in the same conversation.


Andrei

On 9/23/13 1:03 AM, Dicebot wrote:
> On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu wrote:
>> ...
>
> In general I like it though I do agree with concerns mentioned that
> without speculation about high-level API and usage examples it is rather
> hard to evaluate its practical applicability. For example, you have
> mentioned somewhere in comments that it is planned to embed allocator as
> part of template site like in C++ and it does not really sound a good idea.

That is undecided at this point. It's possible that we collectively get convinced the efficiency impact of indirect calls is not too high, in which case we can have containers using a dynamic allocator interface.

Andrei

On 9/23/13 4:39 AM, Andrej Mitrovic wrote:
> On 9/23/13, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>> Why "ubyte[]" and not "void[]"?
>
> Probably to make the GC avoid scanning into the array.

No, that's determined at runtime by how the blocks are allocated.

Andrei

On 9/23/13 7:07 AM, Manu wrote:
> On 24 September 2013 00:04, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 9/22/13 10:20 PM, Benjamin Thaut wrote:
>
>         Am 23.09.2013 01:49, schrieb Andrei Alexandrescu:
>
>             Hello,
>
>
>             2. Untyped allocator - traffics exclusively in ubyte[].
>
>
>         Why "ubyte[]" and not "void[]"?
>
>
>     It's the logical choice at this level.
>
>     ubyte[] == "these are octets"
>
>
> Isn't that what void[] also means?
> Except it says "these are un-typed octets, ie, not a sequence of typed
> integers in the range 0-255".

I think void[] means "objects of unknown type".

Andrei

On 2013-09-23, 15:58, Andrei Alexandrescu wrote:

>> I had imagined going into this that, like the range interface which the
>> _language_ understands and interacts with, the allocator interface would
>> be the same, ie, the language would understand this API and integrate it
>> with 'new', and the GC... somehow.
>
> The D language has no idea what a range is. The notion is completely defined in std.range.

The language has some knowledge of ranges, or foreach (e; myRange) would
not work.

-- 
  Simen