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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,72137304956d9360 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-23 12:04:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: generic imports? void* -> generics? Date: Tue, 23 Sep 2003 14:07:04 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:42820 Date: 2003-09-23T14:07:04-05:00 List-Id: "Simon Wright" wrote in message news:x7vvfrkukgp.fsf@smaug.pushface.org... > "Randy Brukardt" writes: > > > The Claw package puts the stream element array inside of the wrapper > > type. (The access discriminant is interesting, but it couldn't be > > used on slices or any constrained object, which would make it > > annoying to use.) That makes it a buffer. Usually, it is used by > > 'loading' the buffer by calling Write explicitly, then using the > > stream routines to read from it. (Or vice versa). > > Yes, I have BC.Support.Memory_Streams which is like that. No trouble > if I'm starting from an empty stream. But if I've read the data over > the network, say, I need to copy the data into the buffer .. I think > my problem is, providing too much encapsulation, which limits what > users can do with the package. If I want to > > create a streaming buffer > read data from a socket that has to write to a stream_element_array, > cos it's datagram-oriented, directly into the buffer > > I probably have to make the buffer part of the stream visible. We didn't do that because we wanted the buffer to be able to hold any amount of data. That requires behind-the-scenes memory allocation, and that insists on a private type. For the short items that we were primarily concerned about (registry, clipboard, etc.), the extra copy is not too bad. > The new version looks like > > package BC.Support.Array_Streams is > > type Stream_Type > (Buffer : access Ada.Streams.Stream_Element_Array) > is new Ada.Streams.Root_Stream_Type with private; > -- Provides an in-memory Stream over the elements of Buffer. > -- > -- When one of these Stream_Types is created, it is notionally > -- empty. If Buffer is not in fact empty (perhaps it has been read > -- from a datagram socket), use Set_Last to indicate the index of > -- the last valid element. > > function Last (Used_In : Stream_Type) > return Ada.Streams.Stream_Element_Offset; > -- Returns the index in Used_In's Stream_Element_Array of the last > -- used element. > > procedure Set_Last (Used_In : in out Stream_Type; > To : Ada.Streams.Stream_Element_Offset); > -- Sets the index of the last valid element in Used_In's > -- Stream_Element_Array. > > procedure Reset (Stream : out Stream_Type); > -- Clears Stream. > > private > > which is going to require some care to use! I would consider providing both. This will be hard to use, because you have to declare an aliased, unconstrained buffer to be able to match the discriminant. Buf : aliased Stream_Element_Array (1..10); won't work. Also, in many cases, you end up copying the data anyway; you might as well use Write to do that. > On a style issue, do you think I should make Stream_Type's Read, Write > operations (which must be present because of the derivation from > Root_Stream_Type) visible? I always put overridings into the private part. A user shouldn't care whether an operation is overridden; that's an implementation detail. > I ask because (in another package) I had a Controlled type with a > visible Initialize and someone mistakenly called it .. I know they > could have done anyway, but its being there in the public part of the > package tempted them. It's best if the abstraction can withstand extra calls to Initialize and Adjust; it has to withstand extra calls to Finalize (as they can happen in abort situations). Randy.