std.allocator ready for some abuse

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 12 03:10:27 PST 2015


On Thursday, 12 February 2015 at 08:56:53 UTC, ANtlord wrote:
> On Wednesday, 11 February 2015 at 15:56:07 UTC, Andrei 
> Alexandrescu wrote:
>> On 2/11/15 4:55 AM, ANtlord wrote:
>>> On Monday, 17 February 2014 at 15:49:27 UTC, Andrei 
>>> Alexandrescu wrote:
>>>> On 2/17/14, 5:55 AM, Dicebot wrote:
>>>>> Andrei, what is current state of std.allocator? I am asking 
>>>>> this in
>>>>> context of recent Walter Phobos proposal (ScopeBuffer) to 
>>>>> evaluate how
>>>>> feasible is to define any relations between two at current 
>>>>> stage.
>>>>
>>>> Progress on std.allocator is slow but I do have a plan. I 
>>>> don't think
>>>> we should pull ScopeBuffer yet.
>>>>
>>>> Andrei
>>>
>>> Mr. Alexandrescu. What about std allocator? Is feature 
>>> valuable? I've
>>> took a look in Wish List in wiki and Allocator still there.
>>> If this feature is valuable. What is left in currently 
>>> implementation of
>>> your project? Can you tell about state, maybe show To Do list?
>>>
>>> Sorry, if my english is not clear. Thank you.
>>
>> Interface with garbage collector is to be done. The rest is 
>> usable right now. -- Andrei
>
> I thought, that general purpose of allocator it is memory 
> management without garbage collector. Because allocator will be 
> used in containers, and they must work without garbage 
> collector. If no, what is difference between containers and 
> arrays in current implementation of D? I assumed, that 
> containers are need for increased performance within saving 
> safety code. But a using GC will not increase performance.
>
> Or Am I dead wrong?

You still need to cooperate with the GC and let it know which 
memory should be hands off, for example.

Or just use it for the initial allocation and then ask it 
politely to release ownership of it.

--
Paulo


More information about the Digitalmars-d mailing list