On 2013-10-25 03:08, Walter Bright wrote:

> This is not a comment on the allocator design, but the module layout.
>
> Would it be possible that this use the "package" idea with one allocator
> per file instead of the all-in-one-file setup?

Yes, please.

-- 
/Jacob Carlborg

On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
> On 10/24/13 2:38 PM, Namespace wrote:
>> On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
>>> Awesome! Will Appender get an option to use a suitable allocator?
>>
>> A dream of me, that will probably never come true, would be also
>> something like this:
>> ----
>> with (Mallocator) {
>>     int[] arr;
>>     arr ~= 42; /// will use Mallocator.it.allocate internal
>> }
>> ----
>
> Oddly enough this can be actually done.
>
> with (setAllocator!Mallocator)
> {
>    ...
> }
>
> setAllcator returns an rvalue that changes the global allocator to the Mallocator in the constructor, and restores it to whatever it was in the destructor.
>
>
> Andrei

Are you saying that this code:
----
with (setAllocator!Mallocator) {
    int[] arr;
    arr ~= 42; [1]
}
----
use the mallocator for [1]? So no GC memory is needed?

Another examaple:
----
with (setAllocator!ScopeAllocator) {
    int[] arr;
    arr ~= 42; [1]
}
----
Did [1] use ScopeAllocator for memory allocation? And is the memory of arr automatically collected at the end of the scope with ScopeAllocator?

Am Fri, 25 Oct 2013 00:33:40 +0200
schrieb "Namespace" <rswhite4@googlemail.com>:

> Another idea would be that every built-in array has a Allocator property which can be set:
> ----
> int[] arr;
> arr.allocator = Mallocator;
> ----

The type of arr.allocator would have to be CAllocator to allow runtime swapping of allocators with polymorphism.

Would you'd implement it like .capacity, as a virtual property that doesn't take up space in the slice?

-- 
Marco

On Friday, 25 October 2013 at 01:00:04 UTC, Michel Fortin wrote:
> On 2013-10-25 00:20:41 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>
>> If that happens, perhaps AffixAllocator!(A, size_t) could be of use by sticking the allocated size just before the allocation. But then you have a different problem - tapping into possibly cold memory when deallocating.
>
> The size is already available in the classinfo, but the underlying allocator doesn't need it when deallocating (the size part will get ignored). The goal is to not have to give the size to deallocate when it doesn't need it (to save you from retrieving it). All you need is to know that deallocate() ignores the size part of the given array telling you whether or not it's safe to call deallocate(pointer[0..0]). You could add an optional "deallocateIgnoresSize" property for that.
>
> By the way, I think the idea of adding a boolean property for this offers less room for misuse than adding an optional deallocate(void*b) overload. With an overload you're duplicating the API and it won't be immediately clear whether or not it's best to provide the size.
>
> But I'm still not sure it's worth the trouble. I'll leave others be the judge of that.

A void deallocate(void* b) overload might be good in these cases.

On Friday, 25 October 2013 at 07:50:00 UTC, Marco Leise wrote:
> Am Fri, 25 Oct 2013 00:33:40 +0200
> schrieb "Namespace" <rswhite4@googlemail.com>:
>
>> Another idea would be that every built-in array has a Allocator property which can be set:
>> ----
>> int[] arr;
>> arr.allocator = Mallocator;
>> ----
>
> The type of arr.allocator would have to be CAllocator to allow
> runtime swapping of allocators with polymorphism.
>
> Would you'd implement it like .capacity, as a virtual property
> that doesn't take up space in the slice?

Yes I would, but it's not up to me. But I would prefer this solution because it is more flexible IMO.

On Friday, 25 October 2013 at 07:19:48 UTC, Namespace wrote:
> On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
>> On 10/24/13 2:38 PM, Namespace wrote:
>>> On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
>>>> Awesome! Will Appender get an option to use a suitable allocator?
>>>
>>> A dream of me, that will probably never come true, would be also
>>> something like this:
>>> ----
>>> with (Mallocator) {
>>>    int[] arr;
>>>    arr ~= 42; /// will use Mallocator.it.allocate internal
>>> }
>>> ----
>>
>> Oddly enough this can be actually done.
>>
>> with (setAllocator!Mallocator)
>> {
>>   ...
>> }
>>
>> setAllcator returns an rvalue that changes the global allocator to the Mallocator in the constructor, and restores it to whatever it was in the destructor.
>>
>>
>> Andrei
>
> Are you saying that this code:
> ----
> with (setAllocator!Mallocator) {
>     int[] arr;
>     arr ~= 42; [1]
> }
> ----
> use the mallocator for [1]? So no GC memory is needed?
>
> Another examaple:
> ----
> with (setAllocator!ScopeAllocator) {
>     int[] arr;
>     arr ~= 42; [1]
> }
> ----
> Did [1] use ScopeAllocator for memory allocation? And is the memory of arr automatically collected at the end of the scope with ScopeAllocator?

This is impossible because with() has already another meaning. However nothing stops from inventing another name for this. Compiler can insert calls to druntime as well to other context dependent functions. After allocator design is defined we can move on to step 2, implementing this idea.

>> Are you saying that this code:
>> ----
>> with (setAllocator!Mallocator) {
>>    int[] arr;
>>    arr ~= 42; [1]
>> }
>> ----
>> use the mallocator for [1]? So no GC memory is needed?
>>
>> Another examaple:
>> ----
>> with (setAllocator!ScopeAllocator) {
>>    int[] arr;
>>    arr ~= 42; [1]
>> }
>> ----
>> Did [1] use ScopeAllocator for memory allocation? And is the memory of arr automatically collected at the end of the scope with ScopeAllocator?
>
> This is impossible because with() has already another meaning. However nothing stops from inventing another name for this. Compiler can insert calls to druntime as well to other context dependent functions. After allocator design is defined we can move on to step 2, implementing this idea.

You mena something like this?
----
use(Mallocator) {
    int[] arr;
    arr ~= 42;
}
----
Or did I understand you wrong?

Whats about the virtual property idea, that every array has internal an allocator? Wouldn't it be easier to implement such a thing?

On Friday, 25 October 2013 at 08:13:21 UTC, Namespace wrote:
>>> Are you saying that this code:
>>> ----
>>> with (setAllocator!Mallocator) {
>>>   int[] arr;
>>>   arr ~= 42; [1]
>>> }
>>> ----
>>> use the mallocator for [1]? So no GC memory is needed?
>>>
>>> Another examaple:
>>> ----
>>> with (setAllocator!ScopeAllocator) {
>>>   int[] arr;
>>>   arr ~= 42; [1]
>>> }
>>> ----
>>> Did [1] use ScopeAllocator for memory allocation? And is the memory of arr automatically collected at the end of the scope with ScopeAllocator?
>>
>> This is impossible because with() has already another meaning. However nothing stops from inventing another name for this. Compiler can insert calls to druntime as well to other context dependent functions. After allocator design is defined we can move on to step 2, implementing this idea.
>
> You mena something like this?
> ----
> use(Mallocator) {
>     int[] arr;
>     arr ~= 42;
> }
> ----
> Or did I understand you wrong?

It depends on how Mallocator is related to integer array (which again boils down to allocator design). If it is appropriate, then yes.

>
> Whats about the virtual property idea, that every array has internal an allocator? Wouldn't it be easier to implement such a thing?

Please provide example.

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.

Does anyone has good resources on allocators in general? I've mostly used malloc/free and GCs. None of the books I've read has gone into allocators..

>> You mena something like this?
>> ----
>> use(Mallocator) {
>>    int[] arr;
>>    arr ~= 42;
>> }
>> ----
>> Or did I understand you wrong?
>
> It depends on how Mallocator is related to integer array (which again boils down to allocator design). If it is appropriate, then yes.
>
>>
>> Whats about the virtual property idea, that every array has internal an allocator? Wouldn't it be easier to implement such a thing?
>
> Please provide example.

Something like that: http://forum.dlang.org/thread/l4btsk$5u8$1@digitalmars.com?page=3#post-pfoxyfzyjxqcqwnvgnpi:40forum.dlang.org

Every array has an internal allocator property which can be reset:
----
int[] arr;
arr.allocator = Mallocator;
----

or

----
int[] arr;
arr.useAllocator(Mallocator);
----

But maybe a design without some alias notation would be more preferable:
----
{
    ScopeAllocator m;
    int[] arr;
    arr.useAllocator(m);

    arr ~= 42; /// Use m.allocate
} /// end of scope: ScopeAllocator collects all remaining memory.
----

And:
----
int[] arr;
assert(arr is null);
{
    ScopeAllocator m;
    arr.useAllocator(m);

    arr ~= 42; /// Use m.allocate
} /// end of scope: ScopeAllocator collects all remaining memory.
assert(arr is null);
----