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