* Re: Ada.Storage_IO. Anyone use it? [not found] <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com> @ 2012-06-09 8:36 ` Dmitry A. Kazakov 2012-06-09 14:09 ` Georg Bauhaus 2012-06-09 14:24 ` anon 1 sibling, 1 reply; 4+ messages in thread From: Dmitry A. Kazakov @ 2012-06-09 8:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Ada.Storage_IO. Anyone use it? 2012-06-09 8:36 ` Ada.Storage_IO. Anyone use it? Dmitry A. Kazakov @ 2012-06-09 14:09 ` Georg Bauhaus 0 siblings, 0 replies; 4+ messages in thread From: Georg Bauhaus @ 2012-06-09 14:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Ada.Storage_IO. Anyone use it? [not found] <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com> 2012-06-09 8:36 ` Ada.Storage_IO. Anyone use it? Dmitry A. Kazakov @ 2012-06-09 14:24 ` anon 1 sibling, 0 replies; 4+ messages in thread From: anon @ 2012-06-09 14:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Ada.Storage_IO. Anyone use it? @ 2012-06-09 8:18 Micronian Coder 0 siblings, 0 replies; 4+ messages in thread From: Micronian Coder @ 2012-06-09 8:18 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-06-09 14:24 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com> 2012-06-09 8:36 ` Ada.Storage_IO. Anyone use it? Dmitry A. Kazakov 2012-06-09 14:09 ` Georg Bauhaus 2012-06-09 14:24 ` anon 2012-06-09 8:18 Micronian Coder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox