From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2e66fe8b30e3ee2c X-Google-Attributes: gid103376,public From: tmoran@bix.com Subject: Re: S'Write and How To Count Bytes Date: 2000/10/02 Message-ID: #1/1 X-Deja-AN: 676725023 References: <8raa11$nmg$1@nnrp1.deja.com> X-Complaints-To: abuse@home.net X-Trace: news1.frmt1.sfba.home.com 970511474 24.20.190.201 (Mon, 02 Oct 2000 11:31:14 PDT) Organization: @Home Network NNTP-Posting-Date: Mon, 02 Oct 2000 11:31:14 PDT Newsgroups: comp.lang.ada Date: 2000-10-02T00:00:00+00:00 List-Id: 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.