On 5 December 2013 10:13, Michel Fortin <[email protected]> wrote:
> On 2013-12-04 23:14:48 +0000, Andrei Alexandrescu < > [email protected]> said: > > Walter and I were talking about eliminating the surreptitious allocations >> in buildPath: >> >> http://dlang.org/phobos/std_path.html#.buildPath >> >> We'd need to keep the existing version working, so we're looking at >> adding one or more new overloads. We're looking at giving the user the >> option to control any needed memory allocation (or even arrange things such >> that there's no memory allocated at all). >> >> It's a generous design space, so although we have a couple of ideas let's >> hear others first. >> > > Allow an allocator as the first argument. Then pass an allocator that uses > preallocated memory (or any other strategy that does not really need to > allocate). While technically the allocator still "allocates" memory, since > you control the allocator it does it the you can redefine "allocate" to not > allocate. > Allocator as the first argument? This is so you can use UFCS on the allocator to make the call? I think it maybe makes sense for a function that takes an output range to receive it as the first argument for this reason: outputRange.myFunction(); // I'm not sure if I like this, not sure it's communicating the right process... but maybe people find it convenient? An overload that receives an allocator though, I'd probably make the allocator the last argument, this way it can have a default arg that is the default GC allocator, thus eliminating the other (original?) overload of the function which receives neither an output range or an allocator (using the GC intrinsically). Here's a funny thought: allow plain arrays to be *typed* allocators through > UFCS, just like arrays are ranges. If you have an array of chars, then > "allocating" from it will simply return a slice and "bump the pointer" by > becoming the remaining unused slice. The big problem with buildPath is that > it won't work with overloading because your allocator has the same type as > the other parameters. You'll need to wrap it in some kind of allocator > shell. :-/ I'm not sure I like this idea. I think I'd prefer to see 2 overloads, one that receives an output range, and one that receives an allocator (which may default to a GC allocator?).
