Great news! It looks like a big improvement on akward C++ allocators.

(For what it's worth I have a working implementation of aligned malloc/free/realloc here https://github.com/p0nce/gfm/blob/master/gfm/core/memory.d, which can be the basis for an allocator layered upon another)

"Simen Kjaeraas" <simen.kjaras@gmail.com> wrote:
> 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.

Great point. I amend my claim.

Andrei

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

> 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).)


delete is important if your class is being allocated by a pool or
something...
But you said before, people won't use 'new' if they are using an allocator.
I'm really not sure that's a good idea.
Most people (library authors!) don't actually care about their memory
allocation, they will continue to use 'new', just because it's a keyword.
It also screws with generic code; X should be allocated with 'new', but Y
should be allocated with yAllocator.alloc()?
What if you decide that Z, which allocates with 'new', becomes a problem
and you want to switch it into a pool? You now need to track down every
instance of 'new Z', and change it.

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

> "Simen Kjaeraas" <simen.kjaras@gmail.com> wrote:
> > 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.
>
> Great point. I amend my claim.
>

Mmm, precisely what I was talking about.

On 9/23/13 7:22 AM, ponce wrote:
> Great news! It looks like a big improvement on akward C++ allocators.
>
> (For what it's worth I have a working implementation of aligned
> malloc/free/realloc here
> https://github.com/p0nce/gfm/blob/master/gfm/core/memory.d, which can be
> the basis for an allocator layered upon another)

Awesome, thanks. Will look at it.

Andrei

We should really deprecate the new keyword. It'd break like all code ever, but with D's templates, there's no need for it, and when it is there, it is going to spark problems about replacing global allocators or the library allocators being second class citizens.

Maybe we could minimize the breakage by just rewriting the keyword into a library function call, which could then be overridden with local variables or imports  via normal scoping.

On 9/23/13 7:50 AM, Manu wrote:
> delete is important if your class is being allocated by a pool or
> something...

It's important as an API function, but not as a language primitive. "new" should also have been a function.

> But you said before, people won't use 'new' if they are using an
> allocator. I'm really not sure that's a good idea.

I don't see another way if people are to define and use multiple allocators.

> Most people (library authors!) don't actually care about their memory
> allocation, they will continue to use 'new', just because it's a keyword.

"new considered harmful" etc.

> It also screws with generic code; X should be allocated with 'new', but
> Y should be allocated with yAllocator.alloc()?
> What if you decide that Z, which allocates with 'new', becomes a problem
> and you want to switch it into a pool? You now need to track down every
> instance of 'new Z', and change it.

We can only improve that situation by allowing people to replace the global allocator with their own allocators. Again, there's a disconnect here - I'm discussing "how to make it easy for people to define allocators" and you discuss "how to make it possible for people to plug allocators, once defined, as the global allocator". These are two distinct endeavors. At the level I'm at, I'm concerned with making good allocators easy to implement. You may say you don't care, and that's good feedback, but it's what I have for the time being.


Andrei

On 9/23/13 8:02 AM, Adam D. Ruppe wrote:
> We should really deprecate the new keyword. It'd break like all code
> ever, but with D's templates, there's no need for it, and when it is
> there, it is going to spark problems about replacing global allocators
> or the library allocators being second class citizens.
>
> Maybe we could minimize the breakage by just rewriting the keyword into
> a library function call, which could then be overridden with local
> variables or imports  via normal scoping.

I'd think new already is translated into a library call. Walter?

Andrei

On 9/23/13 7:22 AM, ponce wrote:
> Great news! It looks like a big improvement on akward C++ allocators.
>
> (For what it's worth I have a working implementation of aligned
> malloc/free/realloc here
> https://github.com/p0nce/gfm/blob/master/gfm/core/memory.d, which can be
> the basis for an allocator layered upon another)

I gave this a read, nice work.

One question: what circumstances require run-time alignment values, and what values would those be? I'm currently under the assumption that alignments are known during compilation.


Thanks,

Andrei

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

> On 9/23/13 7:50 AM, Manu wrote:
>
>> delete is important if your class is being allocated by a pool or something...
>>
>
> It's important as an API function, but not as a language primitive. "new" should also have been a function.


I like operator new. It goes blue, and the statement isn't riddled with
exclamation marks.
Imagine if new was a template (it would have to be a template). Allocating
a template would require nested template syntax every time, which is pretty
ugly.

  X x = new!(X!arg(args...)); // ewoo, paren spam...

 But you said before, people won't use 'new' if they are using an
>> allocator. I'm really not sure that's a good idea.
>>
>
> I don't see another way if people are to define and use multiple allocators.


Well if an allocator is somehow associated with a class/struct, then 'new
MyClass' would invoke that allocator.
If you:
  pushThreadAllocator(myAllocator);
  X x = new X;
  popThreadAllocator();

Then new will use your thread-local allocator.
Continue for global, fiber, etc.

Maybe there's opportunity for 'scope' to offer some nice convenience here?

 Most people (library authors!) don't actually care about their memory
>> allocation, they will continue to use 'new', just because it's a keyword.
>>
>
> "new considered harmful" etc.
>
>
>  It also screws with generic code; X should be allocated with 'new', but
>> Y should be allocated with yAllocator.alloc()?
>> What if you decide that Z, which allocates with 'new', becomes a problem
>> and you want to switch it into a pool? You now need to track down every
>> instance of 'new Z', and change it.
>>
>
> We can only improve that situation by allowing people to replace the global allocator with their own allocators. Again, there's a disconnect here - I'm discussing "how to make it easy for people to define allocators" and you discuss "how to make it possible for people to plug allocators, once defined, as the global allocator". These are two distinct endeavors. At the level I'm at, I'm concerned with making good allocators easy to implement. You may say you don't care, and that's good feedback, but it's what I have for the time being.


Well, I'm discussing "how do people affect/override 'new' in various circumstances?"

But sure, I said before, if we're limiting this discussion to the API of an
allocator then it looks fine, I see no obvious issues.
But I think the question requires consideration of the intended goal to
make informed decisions about the design, even at this level.