• ref2401 (14/14) Oct 29 2015 As I understand the `std.experimental.allocator` package will be
• Rikki Cattermole (2/16) Oct 29 2015 Take a look at the functions theAllocator and processAllocator.
• ref2401 (5/6) Oct 29 2015 It would be greate if compiler were able to use `theAllocator`
• ref2401 (7/10) Oct 29 2015 I should have suggested different names if don't like present
• Rikki Cattermole (7/16) Oct 29 2015 What I normally do for memory to be owned by the thread is:
• ref2401 (3/9) Nov 01 2015 What do other think?
• Jeffery (22/35) Nov 01 2015 Create a "repository" of allocators. The "programmers" query the

ref2401 <refactor24 gmail.com> writes:

As I understand the `std.experimental.allocator` package will be 
included in the upcoming DMD 2.069 release. I like the idea of 
composable allocators. Though I've got a question which I can not 
answer myself.

Let's assume a team which is developing an application that can 
benefit from usage of different allocation strategies. When a 
programmer implements a function/struct/class he may use whatever 
allocator he thinks fits his needs best. At some point the source 
code is going to be a mess because there will be so many places 
where different allocation strategies are used.
The question. Could you suggest robust practices, how to avoid 
designing such messy code?

Any information is appreciated.
Thank you.

Rikki Cattermole <alphaglosined gmail.com> writes:

On 30/10/15 7:56 AM, ref2401 wrote:
 As I understand the `std.experimental.allocator` package will be
 included in the upcoming DMD 2.069 release. I like the idea of
 composable allocators. Though I've got a question which I can not answer
 myself.

 Let's assume a team which is developing an application that can benefit
 from usage of different allocation strategies. When a programmer
 implements a function/struct/class he may use whatever allocator he
 thinks fits his needs best. At some point the source code is going to be
 a mess because there will be so many places where different allocation
 strategies are used.
 The question. Could you suggest robust practices, how to avoid designing
 such messy code?

 Any information is appreciated.
 Thank you.

Take a look at the functions theAllocator and processAllocator.

ref2401 <refactor24 gmail.com> writes:

On Friday, 30 October 2015 at 01:26:17 UTC, Rikki Cattermole 
wrote:
 Take a look at the functions theAllocator and processAllocator.

It would be greate if compiler were able to use `theAllocator` 
and `processAllocator` but they don't seem much helpfull. 
Terrible naming by the way.

ref2401 <refactor24 gmail.com> writes:

On Friday, 30 October 2015 at 04:11:05 UTC, ref2401 wrote:
 It would be greate if compiler were able to use `theAllocator` 
 and `processAllocator` but they don't seem much helpfull. 
 Terrible naming by the way.

I should have suggested different names if don't like present 
ones.
if `processAllocator` stands for the whole process then there 
must be `threadAllocator` as well. But that's not the question.
I would like to know about usage strategies of various allocators 
within the same code.

Rikki Cattermole <alphaglosined gmail.com> writes:

On 30/10/15 5:27 PM, ref2401 wrote:
 On Friday, 30 October 2015 at 04:11:05 UTC, ref2401 wrote:
 It would be greate if compiler were able to use `theAllocator` and
 `processAllocator` but they don't seem much helpfull. Terrible naming
 by the way.

 I should have suggested different names if don't like present ones.
 if `processAllocator` stands for the whole process then there must be
 `threadAllocator` as well. But that's not the question.
 I would like to know about usage strategies of various allocators within
 the same code.

What I normally do for memory to be owned by the thread is:

auto foo(IAllocator alloc=theAllocator()) {...}

Where as for if it is global to the process:

auto foo(IAllocator alloc=processAllocator()) {...}

Basically it is the difference between a screenshot of a display and a 
window instance.

ref2401 <refactor24 gmail.com> writes:

On Friday, 30 October 2015 at 05:21:17 UTC, Rikki Cattermole 
wrote:
 What I normally do for memory to be owned by the thread is:

 auto foo(IAllocator alloc=theAllocator()) {...}

 Where as for if it is global to the process:

 auto foo(IAllocator alloc=processAllocator()) {...}

 Basically it is the difference between a screenshot of a 
 display and a window instance.

What do other think?

Jeffery <Jeffery gmail.com> writes:

On Sunday, 1 November 2015 at 09:48:20 UTC, ref2401 wrote:
 On Friday, 30 October 2015 at 05:21:17 UTC, Rikki Cattermole 
 wrote:
 What I normally do for memory to be owned by the thread is:

 auto foo(IAllocator alloc=theAllocator()) {...}

 Where as for if it is global to the process:

 auto foo(IAllocator alloc=processAllocator()) {...}

 Basically it is the difference between a screenshot of a 
 display and a window instance.

 What do other think?

Create a "repository" of allocators. The "programmers" query the 
allocators for their "best fit", but because it is a repository, 
they are easier to deal with than hard coding.

E.g.,

auto allocator = 
GetAllocator(allocatorsRepository.processAllocator);

GetAllocator would get the actual allocator using the arg as a 
"hint".

One could, hypothetically, make this as complex as one would 
want. e.g., passing the file name as an argument(hidden) which 
can then be used as a constraint on the allocator allocation(pun 
;). e.g., you can have file specific optimization techniques by 
altering the allocation strategy per file(or better yet, per 
line).

Since all that can be done retroactively, it alleviates some of 
the problems with the programmers interfacing directly with 
std.experimental.allocator. They have to go through your 
interface first which gives you some control.

You could then print special debug messages sort of like -vgc but 
instead, for allocation strategies. The sky's the limit! Have fun 
with it!