well I was curious enough to take a quick look on your ByteRage page, what I do not understand is what is so different from the streams, you page actually describes the tstream based mechanism to the letter
First of all I never proposed that we kick out streams in favour of my buffers, far from it, they complement each other.
If you take a look at the code you will find that it has several advantages over vanilla streams:
** Data view mechanism: You can view/read/write to the buffers using various aux classes (same as C#, C++ and JavaScript). So the same buffer can be accessed as byte, word, longword and even bits. Each "view" targets the same buffer, but regards the buffer content differently. Writing your own view for custom datatypes is simple and elegant.
** Capabilities awareness: Buffers provide info on their caps (e.g: write allowed, read not allowed, scale allowed)
** Faster than streams, quite substancially since seek has no place. Int64 based offsets all the way
** Provides better functions and operations:
--Insert (which really means insert, not overwrite)
--Remove (which again removes X number of bytes from anywhere in a buffer)
--ZLib support, pack a buffer on the fly
** Easy to expand. A memory mapped file version is trivial. A http buffer likewise so (loading data from the web using the http part + offset API).
** Record classes: binary persistence simplified
** Owned and foreign buffers, simplify access to buffers not allocated by you
For instance, pixelrage, which is a low-level graphics library - uses buffers to deal with all in-memory operations. It doesnt even need a device context, it does everything in memory.
But by altering the buffer type to disk, operations can be done there (all operations, like line, circle, clip, fill, gradient etc. etc). This is quite handy for services which deals with en-mass manipulation (I wrote a huge service for Hydro, a norwegian oil company, and with their security context you couldnt not even create a device context. I was forced to improvise and created pixelrage + byterage)
NOTE: Byterage should not be considered "complete", but rather providing rock solid routines as building blocks for larger systems.
It also ships with a TStream adapter, so you can mix and match buffers with streams.
I actually used the buffer classes to write my own DB engine. And since it uses buffers it works everywhere buffers can go (same benefits as streams, but faster and more flexible).
What is easiest to write:
mBuffer.Pack;
or.. (pseudo):
mPacker:=TCompressionStream.Create(mTarget);
try
mPacker.read(mSource,mSource.Size);
finally
mPacker.free;
end;
As always -- you can chose to ignore subtle differences and advantages of a fast and light buffer system over streams, thats up to you. No one is forcing anyone.
To be frank, the more options FPC/Laz has the better.