Ada.Storage_IO. Anyone use it?

Ada.Storage_IO. Anyone use it?

[Micronian Coder]

Hi,

I was looking through the Ada RM and came across the generic package Ada.Storage_IO. I'm not sure what the benefits are to using it. It states that it could automatically flatten out the data representation if necessary. For example, say a discriminant record has an array field that is sized based on the discriminant value:

type Buffer(Length : Positive) is
    record
       Bytes: Byte_Array(1 .. Length);
    end record;

The implementation chosen by the compiler could have Bytes dynamically allocated rather than embedded (I believe Randy said the Janus/Ada compiler would always have the arrays of this type of record dynamically allocated). Using Ada.Storage_IO would store all the data into a buffer as if it was all together and when read back it could recreate the multi-part representation.

Did anyone find this package useful in practice rather than define their own IO routines (e.g. define stream operations to read and write their data)? I'm really curious.

Thanks!

Re: Ada.Storage_IO. Anyone use it?

[Dmitry A. Kazakov]

On Sat, 9 Jun 2012 01:06:35 -0700 (PDT), Micronian Coder wrote:

> I was looking through the Ada RM and came across the generic package
> Ada.Storage_IO. I'm not sure what the benefits are to using it. It states
> that it could automatically flatten out the data representation if
> necessary. For example, say a discriminant record has an array field that
> is sized based on the discriminant value:
> 
> type Buffer(Length : Positive) is
>     record
>        Bytes: Byte_Array(1 .. Length);
>     end record;

You cannot instantiate Ada.Storage_IO with this type, because Buffer is
indefinite. But since Ada.Storage_IO look totally useless (see A.9(11),
too!) anyway...
 
> Did anyone find this package useful in practice rather than define their
> own IO routines (e.g. define stream operations to read and write their
> data)?

1. For specifically storage I/O I am using memory pools. Instead of Write I
do "new", instead of Read I use an access type. This is cleaner, more
efficient, and no generics involved.

   = Pool, backed by a container, e.g. a segmented memory stack

2. For data exchange I am using streams. I always redefine stream
operations because built-in ones are unusable for data exchange, which
dictates certain representation. Again, no generics, no any limitations of
elements, reusable with different stream backends.

   = Stream, backed by a container.

It is worth to mention that there are three major distinct cases, which get
permanently confused in the context of I/O:

A. Marshaling objects (true I/O, persistency, serialization)
B. Formatted I/O and rendering (dealing with human readable
representations)
C. Garbage collection of objects (e.g. arena allocators etc)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Storage_IO. Anyone use it?

[Georg Bauhaus]

On 09.06.12 10:36, Dmitry A. Kazakov wrote:
> On Sat, 9 Jun 2012 01:06:35 -0700 (PDT), Micronian Coder wrote:
>
>> I was looking through the Ada RM and came across the generic package
>> Ada.Storage_IO. I'm not sure what the benefits are to using it. It states
>> that it could automatically flatten out the data representation if
>> necessary. For example, say a discriminant record has an array field that
>> is sized based on the discriminant value:
>>
>> type Buffer(Length : Positive) is
>>      record
>>         Bytes: Byte_Array(1 .. Length);
>>      end record;
>
> You cannot instantiate Ada.Storage_IO with this type, because Buffer is
> indefinite. But since Ada.Storage_IO look totally useless (see A.9(11),
> too!) anyway...

Ada.Storage_IO is as useful or useless as the other traditional
*_IO packages. For an example of usefulness, I can declare one or
any number of Buffer_Type objects to put items on hold that were
just read form a file ("ungetc"), or will be written to another file
when some condition becomes true. Or, more generally, I can use
Ada.Storage_IO for in-memory buffering *without* leaving the
traditional IO framework. Like when sorting with three "tapes".

The formal Element_Type is definite, but discriminated records might
still work just fine, with defaults. A  wrapped array of bytes
with implementation-defined Positive'Last being the maximum
number of elements seems an unnatural example for use with traditional
*_IO packages.
For other types such as database records, or anything that isn't a
huge in-memory representation of the universe and everything,
Ada.Storage_IO should be fine.

    type Count is range 0 .. 400;
    type List_Of_Things is array (Count range <>) of T;

    type Item_to_Store (Length: Count := 42) is record
       Things : List_of_Things (1 .. Length);
    end record;

There are compilers that do have a working implementation of
Ada.Storage_IO.

Re: Ada.Storage_IO. Anyone use it?

[anon]

Most Storage pools are designed to use a fix size Memory block which also 
help in decreasing memory leaks. The advance is memory access allocation 
speed with garbage collection. The disadvantage is pools can be shared 
between many different data types limiting uses to storage only.

The Storage_IO can be used for "Memory Caches" for virtual storage or 
Indexed memory files such as creating an ISAM type file. In both cases, 
using Storage_IO with Direct_IO is more efficiency than pools.

For a design using both Storage_IO and Storage_Pools could be:

        Direct_IO  --  external virtual storage (multiple caches)
                Storage_IO   --  internal cache (multiple pools)
                        Storage_Pools   --  internal Memory Pool
                                Routine  --  using "new" and "free"


In <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com>, Micronian Coder <micronian2@gmail.com> writes:
>Hi,
>
>I was looking through the Ada RM and came across the generic package Ada.St=
>orage_IO. I'm not sure what the benefits are to using it. It states that it=
> could automatically flatten out the data representation if necessary. For =
>example, say a discriminant record has an array field that is sized based o=
>n the discriminant value:
>
>type Buffer(Length : Positive) is
>    record
>       Bytes: Byte_Array(1 .. Length);
>    end record;
>
>The implementation chosen by the compiler could have Bytes dynamically allo=
>cated rather than embedded (I believe Randy said the Janus/Ada compiler wou=
>ld always have the arrays of this type of record dynamically allocated). Us=
>ing Ada.Storage_IO would store all the data into a buffer as if it was all =
>together and when read back it could recreate the multi-part representation=
>..
>
>Did anyone find this package useful in practice rather than define their ow=
>n IO routines (e.g. define stream operations to read and write their data)?=
> I'm really curious.
>
>Thanks!
>
>--Weston