On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei Alexandrescu wrote:
> Andrei

Anyways, design opinions aside, I would be satisfied if an aligned allocator were included in std.allocators that provided aligned heap memory using allocate()/deallocate(). The rest is just details with no practical relevance for my immediate plans.

  Thanks

On 1/21/17 10:07 PM, bitwise wrote:
> On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei Alexandrescu wrote:
>> Andrei
>
> Anyways, design opinions aside, I would be satisfied if an aligned
> allocator were included in std.allocators that provided aligned heap
> memory using allocate()/deallocate(). The rest is just details with no
> practical relevance for my immediate plans.
>
>   Thanks

That should be easy and useful as an adapter over another allocator that supports alignedAllocate(). Please create an issue for that. Thanks! -- Andrei

On Sunday, 22 January 2017 at 13:21:41 UTC, Andrei Alexandrescu wrote:
> On 1/21/17 10:07 PM, bitwise wrote:
>> On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei Alexandrescu wrote:
>>> Andrei
>>
>> Anyways, design opinions aside, I would be satisfied if an aligned
>> allocator were included in std.allocators that provided aligned heap
>> memory using allocate()/deallocate(). The rest is just details with no
>> practical relevance for my immediate plans.
>>
>>   Thanks
>
> That should be easy and useful as an adapter over another allocator that supports alignedAllocate(). Please create an issue for that. Thanks! -- Andrei

I would, but I'm not sure I can use these allocators.

Ran into this:
http://forum.dlang.org/post/akohcwiotlcrodemhexx@forum.dlang.org

As stated in that thread, I can mark the member instance of the allocator in the container as 'shared', but then, if I use an allocator _without_ 'shared' methods, I get errors as well.

I'm not sure if there is a solution for this, but at this point, I try to just avoid 'shared' at all costs. The fact that Mallocator is thread safe should not stop me from using it in a non-thread safe class, but it does.

On Tuesday, 24 January 2017 at 19:38:31 UTC, bitwise wrote:
>
> I would, but I'm not sure I can use these allocators.
>
> Ran into this:
> http://forum.dlang.org/post/akohcwiotlcrodemhexx@forum.dlang.org
>
> As stated in that thread, I can mark the member instance of the allocator in the container as 'shared', but then, if I use an allocator _without_ 'shared' methods, I get errors as well.
>
> I'm not sure if there is a solution for this, but at this point, I try to just avoid 'shared' at all costs. The fact that Mallocator is thread safe should not stop me from using it in a non-thread safe class, but it does.

So I guess there is no solution for this?

I've written my own allocators at this point, which is not something I did with great joy.

On Sunday, 22 January 2017 at 13:21:41 UTC, Andrei Alexandrescu wrote:
> -- Andrei

After exploring this idea(@safe containers), then looking at std.Array again, it's actually pretty smart. I had concerns about efficiency, but RefCounted seems to force allocation like make_shared<>, eliminating the access overhead I thought was present. It doesn't look like RefCounted will work once allocators are introduced, but you seem to already be working on generalized ref-counted buffers. Well played, sir.

I decided to make my own containers classes, in the hopes that one day, I can just slap @rc in front of them and be done with the GC.