Re: [AD] file slices

[ Thread Index | Date Index | More Archives ]

On 2011-07-19, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Tue, Jul 19, 2011 at 1:27 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> >
> > Is al_get_fslice_size different from al_fsize?
> >
> Err, no... it's exactly the same function. It used to be something
> else, but obviously it's not needed anymore.
> > This seems like a good idea, for keeping the code simpler (although, if
> > you have written the code already..).
> >
> I already wrote the code, but as I was writing it and keeping a list
> of all the "gotchas," it started to seem less and less useful.
> > Does this mean if you want to layer a random access file on top
> > of a sequential file, you will need to manually read from the
> > sequential file and copy the bytes into a memfile?
> >
> Yes, but I was considering a new memfile function. I keep going back
> and forth with myself while writing this email ... Perhaps a single
> function is okay, but I should just make it more simple:
> * If unbuffered, then it must be read-only. The file interface must
> support random access. This is still perfectly useful when loading,
> say, a TGA file from within a larger block of data on a local file.
> * If buffered, then it may be written / appended to, BUT, the data is
> never actually sent to the underlying file.

That still sounds complicated.  I prefer your previous suggestion
to remove any buffering from file slices.  Then file slices are
analogous to sub-bitmaps, and memfiles are analogous to memory bitmaps.

Regarding al_get_fslice_buffer (or whatever).  If the buffer is
expandable then the pointer can be moved, so I guess the pointer will
only be valid until the next write.  The implementation can use multiple
buffer fragments or whatever, up until the user wants a pointer to the


Mail converted by MHonArc 2.6.19+