Re: Allocation strategies question
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?
Re: Allocation strategies question
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!
Re: Allocation strategies question
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.
Re: Allocation strategies question
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.
Re: Allocation strategies question
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.
Re: Allocation strategies question
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.
