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