Re: Stdio.Buffer, need a way to revisit old positions in the output

> Yes, well, apart from the fact that you can't use the add_int32(),
> there is another difficulty here: the sizeof() and the [] operators
> are relative to the start of the buffer.  The start is a moving
> target however, since some of it might have been flushed to the
> descriptor already.

That would very much be true with your solution as well, unless as a
side effect it stopped the data from moving around.

Which would mean that it /has/ to be based on pointer objects, or you
have to combine it with rewind_key, and also add something that
disallows memmoves (which updates both offset and len).

> I'll rethink the deluxe-solution once more.  If I can't come up with
> something which easy to implement, I'll use my original proposal
> first, but I'll document it as being not-for-production use; so that
> if someone implements it the "right" way, I'll fix the driver to the
> new methods.

I could implement _a_ deluxe version rather quickly, actually:

|  object k1 = buffer->start_hstring(size_size);
|  buffer->add()
|  .. add stuff ..
|  k1->end([adjust]);
|  // updates buffer[k1..k1+size-1] to (size_diff+adjust) or if
|  // specified to end an explicit value
!  // if k1 is out of scope, undo sub-adds.

The main difference is that it is not really a sub-buffer, it is a
sort-of pointer. It would also need to block reading past the new add
position.

This is a somewhat over-specialized API, but I have also found myself
wishing for something along those lines, so perhaps it would be useful.

Note that it does not really take all that much time to create new
buffer objects and add those to the buffer:

|  Stdio.Buffer sub = Stdio.Buffer();
|  ... add stuff ...
|  buffer->add_hstring( sub, size );

This is what I do currently.

Granted, it is /somewhat/ slower, but not really slow. It is faster
than using strings. And you can do a few million such operations per
second. And you can even resuse the subbuffer object for added speed,
which should actually make it faster than the
buffer->start... solution unless the packets are very large
(basically, if the memcpy time is bigger than the time it takes to
create and free the object)

-- 
Per Hedbor