Re: S'Write and How To Count Bytes

[tmoran@bix.com]

You can of course have two different "new Root_Stream_Type"s, one
of which merely adds to a counter without actually copying data,
and the other actually does the data copy.  This is certainly
faster for simple but wide things.

But

>The problem with this is that since users can make their own 'Write
>attribute routines, there is no way to calculate this short of actually
>performing the writes.
  So a complex composite structure necessarily makes many subroutine
calls, adding up to a lot of time even if each call itself is fast.

>You see the double-conversion of the record to a stream. That's got to be
>inefficient. If there were some way of knowing in advance how many bytes the
>record was going to take up in the stream, we could save that
>double-conversion.
  I still don't understand.  Is each Integer'Write generating a call to
the IO routine, or is it writing into a buffer, which will be passed
to the IO routine when it contains the entire composite record?  In
the latter case, which I assume to be what you mean, keep a running
total of the number of bytes in the buffer, then
Send(Byte_Count, The_Resulting_Stream_Element_Array)
or do an Integer'Write(S, Byte_Count) to
Byte_Count_Header : Stream_Element_Array(1 .. 4);
and replace a junk initial integer with Buffer(1 .. 4) := Byte_Count_Header;

  Another option of course would be to figure out the maximum size, write
into that size buffer, possibly leaving unfilled junk on the end, and
pass the fixed size buffer to your output routine.  It knows the size so
it can checksum and send the whole fixed size block.  The reader will use
'Read and get the actual data back and never even notice the trailing pads.

>You can't really use the 'Write in that case because you're counting on your
>representation to handle how it looks in the stream. (You might get there by
>accident, but when you're building a communication link to the outside world,
>you've *really* got to be sure it gets into that stream *exactly* the way you
>said it would or you're going to have some really upset people at the other end
>of the wire. Compiler changes could really mess you up there.)
   It seems to me this indicates that Stream_IO may simply be
inappropriate for such an application.  The only way you can really know
where the bytes are is via record rep clauses, or by writing your own
'Writes to handle everything in your records.  If you depend on the
compiler, even for Integer'Write, some compiler might some day decide to
write integers in Roman numeral form, or in some error-correcting code
expanded form, or whatever, and there goes your app.  My understanding
is that the only thing you can depend on from the compiler is the
*sequence* of 'Write calls.