D on next-gen consoles and for game development
Jonathan M Davis
jmdavisProg at gmx.com
Fri May 24 12:44:07 PDT 2013
On Saturday, May 25, 2013 00:33:10 Manu wrote:
> Yeah, I've often wanted API's in that fashion too.
> I wonder if it would be worth creating overloads of allocating functions
> that receive an output buffer argument, rather than return an allocated
> buffer...
> Too messy?
We already have stuff like format vs formattedWrite where one allocates and the
other takes an output range. We should adopt that practice in general. Where
possible, it should probably be done with an overload of the function, but
where that's not possible, we can simply create a new function with a similar
name. Then any function which could allocate has the option of writing to an
output range instead (which could be a delegate or an array or whatever) and
avoid the allocation - though I'm not sure that arrays as output ranges
currently handle running out of space very well, so we might need to figure
something out there to properly deal with the case where there isn't enough
room in the output range (arguably, output ranges need a bit of work in
general though).
Regardless, the main question with regards to messiness is whether we can get
away with creating overloads for existing functions which allocate or whether
we'd be forced to create new ones (possibly using a naming scheme similar to
how we have InPlace, only which indicates that it takes an output range or
doesn't allocate or whatever).
- Jonathan M Davis
More information about the Digitalmars-d
mailing list