Am Mon, 29 Sep 2014 15:11:26 -0700 schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
> On 9/29/14, 10:25 AM, Jacob Carlborg wrote: > > How does allocators fit in this? Will it be an additional argument > > to the function. Or a separate stack that one can push and pop > > allocators to? > > There would be one allocator per thread (changeable) deferring to a > global interlocked allocator. Most algorithms would just use whatever > allocator is installed. > > I know the notion of a thread-local and then global allocator is > liable to cause some an apoplexy attack. But it's time to model > things as they are - memory is a global resource and it ought to be > treated as such. No need to pass allocators around except for special > cases. > > > Andrei > > No need to pass allocators around except for special > cases. So you propose RC + global/thread local allocators as the solution for all memory related problems as 'memory management is not allocation'. And you claim that using output ranges / providing buffers / allocators is not an option because it only works in some special cases? What if I don't want automated memory _management_? What if I want a function to use a stack buffer? Or if I want to free manually? If I want std.string.toStringz to put the result into a temporary stack buffer your solution doesn't help at all. Passing an ouput range, allocator or buffer would all solve this.
