Re: [AD] file slices

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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.

As I have implemented and initially described it, if you have a file
slice that's in the middle of a larger file, the writing becomes
difficult to explain. e.g., Imagine a file "AABBBBCC" with a four byte
slice where the B's are "AA[BBBB]CC". If you append a B (mode "a"),
you now get "AA[BBBBCCB]". Unexpectedly, your slice has grown to
include a couple of C's. Alternatively, if you write a B (mode "w") at
the end, you get "AA[BBBBB]C", and you've overwritten a byte outside
the file.

In both cases, I don't see how that could ever be useful. The slice
should be treated as its own thing. And implementing it such that you
can insert data after the slice but before the next bytes of the
physical file is far too complex of a topic for Allegro to try to
handle across all arbitrary file interfaces.

So by adding the above limitations, there's no need to have to explain
how that works. If you have a buffered slice, you ultimately get
[BBBB] in memory by itself. You can append/write to it as you see fit,
and the interface will pick up those changes while the slice is open.
However, if you want to save those changes, you need to do the work
yourself.

--
Matthew Leverton




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/