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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,127b4bdd944554a9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news3.google.com!news.glorb.com!newsfeed-east.nntpserver.com!nntpserver.com!statler.nntpserver.com!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Separate type for byte arrays Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <87irolhpzo.fsf@mid.deneb.enyo.de> Date: Thu, 4 May 2006 18:17:44 +0200 Message-ID: NNTP-Posting-Date: 04 May 2006 18:17:28 MEST NNTP-Posting-Host: 22969572.newsread4.arcor-online.net X-Trace: DXC=TOE`bJ:gBB1j12nnM8XB1>:ejgIfPPld4jW\KbG]kaM8]kI_X=5Kea6o9=>o;e\`D7[6LHn;2LCV>[ On Thu, 04 May 2006 15:35:39 +0200, Florian Weimer wrote: > Does it make sense to provide low-level I/O interfaces in terms of > octet arrays as well as in terms of strings? In other words, > > procedure Read > (Ch : in out Input_Channel; > Item : out Byte_Array; > Length: out Byte_Count); > > in addition to > > procedure Read > (Ch : in out Input_Channel; > Item : out String; > Length: out Natural); > > ? This is a bit cumbersome. Unfortunately, it's not possible to make > Read itself generic because it's a dispatching subprogram. If you > parameterize the whole I/O subsystem on the element and array type, > you still have the problem that no efficient communication is possible > between two subsystems which store data in different array types > (without using Unchecked_Conversion). The other alternative is to > create some kind of buffer object which can be accessed as octet and > character array. I've implemented this, and it doesn't look quite > right, either. > > Any suggestions? I'm aiming for something similar java.nio.*. The requirements are somewhat unclear. The transport layer deals with octets and the application layer wants strings? If so, then I see nothing wrong with your buffer object approach. Or something with like this: package Abstract_Channel is type Input_Channel is abstract ...; procedure Read (Ch : in out Input_Channel; Item : out Byte_Array; Length: out Byte_Count) is abstract; -- To be implemented procedure Read (Ch : in out Input_Channel'Class; Item : out String; Length: out Natural); -- Uses octet Read internally I would also suggest a function like: function Read_Packet (Ch : access Input_Channel'Class) return String; used as: ... loop declare Packet : String renames Read_Packet (Channel'Access); begin -- Process the packet ... end; end loop; in hope that the compiler wouldn't do an extra copy. In Ada 200Y you could use an anonymous access result, I suppose. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de