Separate type for byte arrays

Separate type for byte arrays

[Florian Weimer]

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.*.

I'm not interested in machines which use strange character sets such
as EBCDIC, or machines whose storage unit or stream element size is
not 8 bit.

Re: Separate type for byte arrays

[Frank J. Lhota]

Florian Weimer wrote:
> ...
> 
> Any suggestions?  I'm aiming for something similar java.nio.*.

Would streams meet your needs?

Re: Separate type for byte arrays

[Florian Weimer]

* Frank J. Lhota:

> Florian Weimer wrote:
>> ...
>> Any suggestions?  I'm aiming for something similar java.nio.*.
>
> Would streams meet your needs?

No, the interface does not cope with partial reads and writes ("Last
is less than Item'Last only if the end of the stream is reached).
Unfortunately, they are common in networking applications, and the
layer below the streams would need protocol-dependent knowledge to
tell whether an end-of-stream condition is reached.

Re: Separate type for byte arrays

[Dmitry A. Kazakov]

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

Re: Separate type for byte arrays

[Jeffrey R. Carter]

Florian Weimer wrote:
> 
> I'm not interested in machines which use strange character sets such
> as EBCDIC, or machines whose storage unit or stream element size is
> not 8 bit.

It's not clear what you're asking. I would think all low-level I/O would 
be done in terms of bytes/storage elements/stream elements; anything 
else (such as String) would be a higher-level abstraction on top of this.

Anyway, given an 8-bit machine, you probably want 
System.Storage_Elements.Storage_Array or 
Ada.Streams.Stream_Element_Array rather than your own byte array type. 
Note that conversions to and from Storage_Array can be done with 
Ada.Storage_IO, avoiding Unchecked_Conversion. Similar things can be 
done with Streams, but it takes a bit more work than using Storage_IO.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29