OutputRanges and slicing/save()

Justin Whear justin at economicmodeling.com
Sat Jan 4 07:53:44 PST 2014


On Saturday, 4 January 2014 at 11:22:03 UTC, Jacob Carlborg wrote:
> On 2014-01-03 23:56, Justin Whear wrote:
>> I've run into a design issue surrounding ranges and am looking 
>> for advice
>> on the best way to proceed.  To illustrate the issue, consider 
>> the
>> Shapefile format: a 100 byte header followed by 
>> variable-length records.
>> The tricky bit is that the header includes a field which 
>> contains the
>> total length of the file (as measured in 16-bit words, 
>> curiously).  The
>> header must be written first, but the total length of the file 
>> isn't
>> known until all the records have been encoded.  When writing 
>> to a File
>> this isn't a problem: write 100 bytes of padding, write the 
>> records, use
>> rewind(), and write the proper header.  It's in the context of 
>> an
>> OutputRange that I don't know how to proceed.  Consider the 
>> most flexible
>> range type: the array.  An array is not an OutputRange, so it 
>> needs to be
>> wrapped in something like std.array.Appender.  Ideally I could 
>> save off
>> the initial state of the range, write a bogus header, write 
>> the records,
>> then jump back and write the proper header.  Unfortunately, 
>> Appender is
>> not a ForwardRange, nor does it appear that the field of 
>> OutputRanges
>> which are also ForwardRanges has been explored.  I'm using the 
>> excellent
>> read, write, and append functions from std.bitmanip, so 
>> write() would fit
>> the bill if only Appender supported slicing.
>
> If you're satisfied with just using arrays and not a general 
> output range you can do something similar to what you did with 
> a file. Add the 100 extra bytes for the header to Appender, 
> then add the contents. Extract the array used for backing in 
> the Appender and fill the proper header.

I guess my larger concern is providing an interface which avoids 
allocation.  In that case, having an overload which accepts an 
array for writing into and signals if it was too small could 
work.  It is a bit disappointing to lose the nice generic 
interface which would really give the user control.


More information about the Digitalmars-d mailing list