comp.lang.ada
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Re: General circular buffer example not tied to any specific type
  2020-07-05 13:25  9%       ` Jeffrey R. Carter
  2020-07-05 15:36  0%         ` Simon Wright
@ 2020-07-06  8:11  0%         ` Simon Wright
  1 sibling, 0 replies; 31+ results
From: Simon Wright @ 2020-07-06  8:11 UTC (permalink / raw)


"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> For any type, a better approach is generic package Ada.Storage_IO, ARM
> A.9 (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-9.html).

Any *definite* type. I don't remember whether that would suit the
original requirement in this thread.

^ permalink raw reply	[relevance 0%]

* Re: General circular buffer example not tied to any specific type
  2020-07-05 18:46  0%           ` Dmitry A. Kazakov
@ 2020-07-05 19:51  0%             ` Simon Wright
  0 siblings, 0 replies; 31+ results
From: Simon Wright @ 2020-07-05 19:51 UTC (permalink / raw)


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 05/07/2020 17:36, Simon Wright wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>>
>>> On 7/5/20 11:52 AM, Simon Wright wrote:
>>>> Simon Wright <simon@pushface.org> writes:
>>>>
>>>>> For the Size, see ARM 13.13.2(2).
>>>>
>>>> 13.13.2(1.2), sorry
>>>
>>> That only works for elementary types. For any type, a better approach
>>> is generic package Ada.Storage_IO, ARM A.9
>>> (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-9.html).
>>
>> As you say, this has the advantage of actually working.
>
> I see no difference. In both cases some kind of type tag need to be
> written and the object's size with it if not derived from the tag.

I was talking about the fact that 'Storage_Size only works for elementary
types.

^ permalink raw reply	[relevance 0%]

* Re: General circular buffer example not tied to any specific type
  2020-07-05 15:36  0%         ` Simon Wright
@ 2020-07-05 18:46  0%           ` Dmitry A. Kazakov
  2020-07-05 19:51  0%             ` Simon Wright
  0 siblings, 1 reply; 31+ results
From: Dmitry A. Kazakov @ 2020-07-05 18:46 UTC (permalink / raw)


On 05/07/2020 17:36, Simon Wright wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> 
>> On 7/5/20 11:52 AM, Simon Wright wrote:
>>> Simon Wright <simon@pushface.org> writes:
>>>
>>>> For the Size, see ARM 13.13.2(2).
>>>
>>> 13.13.2(1.2), sorry
>>
>> That only works for elementary types. For any type, a better approach
>> is generic package Ada.Storage_IO, ARM A.9
>> (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-9.html).
> 
> As you say, this has the advantage of actually working.

I see no difference. In both cases some kind of type tag need to be 
written and the object's size with it if not derived from the tag.

Whether stream Read/Write or storage elements copy is then used changes 
little.

P.S. I never used Storage_IO, I did storage pools instead.

With a ring buffer you go as follows. Make a LIFO of Storage_Elements. 
It could be a descendant of Root_Storage_Pool or else if true parent 
type is already spent (Ada has no full multiple inheritance) use an 
access discriminant in a mix-in:

    type LIFO_Pool (Buffer : not null access LIFO'Class)
       with null record;

The implementation of Allocate with reserve place in Buffer. Allocate 
already has parameter Size_In_Storage_Elements.

You should only pay attention to Alignment and to atomic kicking off old 
elements when new allocation overlaps old elements in the buffer. So the 
element sizes must be stored in the LIFO. Writing into the LIFO will become:

    procedure Push (Buffer : in out LIFO'Class S : String) is
       Pool : LIFO_Pool (Buffer'Unchecked_Access);
       type String_Ptr is access String;
       for String_Ptr'Storage_Pool use Pool;
       Ptr : String_Ptr;
    begin
       Ptr := new String'("Some text");
    end Push;

P.P.S. Beware Ada finalization design bug ARM 7.6.1 (11.1/3): no 
controlled types, also.

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

^ permalink raw reply	[relevance 0%]

* Re: General circular buffer example not tied to any specific type
  2020-07-05 13:25  9%       ` Jeffrey R. Carter
@ 2020-07-05 15:36  0%         ` Simon Wright
  2020-07-05 18:46  0%           ` Dmitry A. Kazakov
  2020-07-06  8:11  0%         ` Simon Wright
  1 sibling, 1 reply; 31+ results
From: Simon Wright @ 2020-07-05 15:36 UTC (permalink / raw)


"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 7/5/20 11:52 AM, Simon Wright wrote:
>> Simon Wright <simon@pushface.org> writes:
>>
>>> For the Size, see ARM 13.13.2(2).
>>
>> 13.13.2(1.2), sorry
>
> That only works for elementary types. For any type, a better approach
> is generic package Ada.Storage_IO, ARM A.9
> (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-9.html).

As you say, this has the advantage of actually working.

^ permalink raw reply	[relevance 0%]

* Re: General circular buffer example not tied to any specific type
  @ 2020-07-05 13:25  9%       ` Jeffrey R. Carter
  2020-07-05 15:36  0%         ` Simon Wright
  2020-07-06  8:11  0%         ` Simon Wright
  0 siblings, 2 replies; 31+ results
From: Jeffrey R. Carter @ 2020-07-05 13:25 UTC (permalink / raw)


On 7/5/20 11:52 AM, Simon Wright wrote:
> Simon Wright <simon@pushface.org> writes:
> 
>> For the Size, see ARM 13.13.2(2).
> 
> 13.13.2(1.2), sorry

That only works for elementary types. For any type, a better approach is generic 
package Ada.Storage_IO, ARM A.9 
(http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-A-9.html).

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

^ permalink raw reply	[relevance 9%]

* Re: Dynamic type system for Ada
  @ 2017-01-24 18:07  9%     ` Jeffrey R. Carter
  0 siblings, 0 replies; 31+ results
From: Jeffrey R. Carter @ 2017-01-24 18:07 UTC (permalink / raw)


On 01/24/2017 02:58 PM, Victor Porton wrote:
>
> All I ask is just an Ada type which would be so flexible that could store
> any kind of a value (just like as a variable in a dynamic language).

You might want to look at type System.Storage_Elements.Storage_Array (ARM 
13.7.1). You can (unchecked) convert most values to and from a Storage_Array of 
the correct size. Package Ada.Storage_IO (ARM A.9) makes it easy to do so for 
definite, unlimited types.

-- 
Jeff Carter
"It is the German who is so uncourteous to his verbs."
A Scandal in Bohemia
122


^ permalink raw reply	[relevance 9%]

* FNV-1
@ 2013-10-30 23:31 11% sbelmont700
  0 siblings, 0 replies; 31+ results
From: sbelmont700 @ 2013-10-30 23:31 UTC (permalink / raw)


Hi,

I did up the following implementation of the FNV1 and FNV1a hashes after needing a decent cross-platform, compiler-independent way to hash things (64-bit pointers, specifically), but it ought to be good for other things as well.  I haven't done any extensive testing, but it seems to suit my needs; perhaps it will suit yours as well.  Any suggestions are welcome, especially tips on better ways to use static expressions, or any cross-platform 'gotchas'.  The code is public domain.

-sb

-- Fowler/Noll/Vo hash functions

with Ada.Containers;

package FNV is

   -- FNV-1 Hash
   generic
      type T is private;
   function FNV1 (Item : T) return Ada.Containers.Hash_Type;

   -- FNV-1a Alternative Hash
   generic
      type T is private;
   function FNV1a (Item : T) return Ada.Containers.Hash_Type;

end FNV;


pragma Assertion_Policy (Check);
with Ada.Storage_IO;

package body FNV is

   subtype FNV_Hash_Type is Ada.Containers.Hash_Type;
   use type FNV_Hash_Type;

   -- Prime Values
   Prime_32   : constant := 2**24  + 2**8 + 16#93#;
   Prime_64   : constant := 2**40  + 2**8 + 16#b3#;
   Prime_128  : constant := 2**88  + 2**8 + 16#3b#;
   Prime_256  : constant := 2**168 + 2**8 + 16#63#;
   Prime_512  : constant := 2**344 + 2**8 + 16#57#;
   Prime_1024 : constant := 2**680 + 2**8 + 16#8d#;

   subtype FNV_Prime_Type is FNV_Hash_Type range 1 .. FNV_Hash_Type'Last;

   K_Prime : constant := (case FNV_Prime_Type'Size is
                           when   32 => Prime_32,
                           when   64 => Prime_64,
                           when  128 => Prime_128,
                           when  256 => Prime_256,
                           when  512 => Prime_512,
                           when 1024 => Prime_1024,
                           when others => 0);

   Prime  : constant FNV_Prime_Type := K_Prime;

   -- Start Offset Values
   Offset_32   : constant := 2166136261;
   Offset_64   : constant := 14695981039346656037;
   Offset_128  : constant := 144066263297769815596495629667062367629;
   Offset_256  : constant := 100029257958052580907070968620625704837092796014241193945225284501741471925557;
   Offset_512  : constant := 9659303129496669498009435400716310466090418745672637896108374329434462657994582932197716438449813051892206539805784495328239340083876191928701583869517785;
   Offset_1024 : constant := 14197795064947621068722070641403218320880622795441933960878474914617582723252296732303717722150864096521202355549365628174669108571814760471015076148029755969804077320157692458563003215304957150157403644460363550505412711285966361610267868082893823963790439336411086884584107735010676915;

   subtype FNV_Offset_Type is FNV_Hash_Type range 1 .. FNV_Hash_Type'Last;

   K_Offset : constant := (case FNV_Offset_Type'Size is
                           when   32 => Offset_32,
                           when   64 => Offset_64,
                           when  128 => Offset_128,
                           when  256 => Offset_256,
                           when  512 => Offset_512,
                           when 1024 => Offset_1024,
                           when others => 0);

   Offset : constant FNV_Offset_Type := K_Offset;

   -----------------------------------------------------------------------------
   -- FNV1 Hash Function
   -----------------------------------------------------------------------------
   function FNV1 (Item : T) return Ada.Containers.Hash_Type is

      package Data_Buffers is new Ada.Storage_IO (Element_Type => T);
      Buffer : Data_Buffers.Buffer_Type;

   begin

      Data_Buffers.Write (Buffer => Buffer,
                          Item   => Item);

      return Hash : FNV_Hash_Type := Offset do

         for Byte of Buffer loop
            Hash := Hash * Prime;
            Hash := Hash xor FNV_Hash_Type(Byte);
         end loop;

      end return;
   end FNV1;


   -----------------------------------------------------------------------------
   -- FNV1a Hash Function
   -----------------------------------------------------------------------------
   function FNV1a (Item : T) return Ada.Containers.Hash_Type is

      package Data_Buffers is new Ada.Storage_IO (Element_Type => T);
      Buffer : Data_Buffers.Buffer_Type;

   begin

      Data_Buffers.Write (Buffer => Buffer,
                          Item   => Item);

      return Hash : FNV_Hash_Type := Offset do

         for Byte of Buffer loop
            Hash := Hash xor FNV_Hash_Type(Byte);
            Hash := Hash * Prime;
         end loop;

      end return;
   end FNV1a;

end FNV;


^ permalink raw reply	[relevance 11%]

* Re: Ada.Storage_IO: applied example?
  2012-10-23 20:28  9% ` Dmitry A. Kazakov
  2012-10-23 20:56  8%   ` Yannick Duchêne (Hibou57)
@ 2012-10-23 21:02  9%   ` Jeffrey Carter
  2012-10-24  7:20  9%     ` Dmitry A. Kazakov
  2012-10-24  5:03  9%   ` J-P. Rosen
  2 siblings, 1 reply; 31+ results
From: Jeffrey Carter @ 2012-10-23 21:02 UTC (permalink / raw)


On 10/23/2012 01:28 PM, Dmitry A. Kazakov wrote:
> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
>
>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>
> It looks useless at first glance. The buffer size is fixed and
> implementation defined(!). Why would anybody use that rather than plain
> array?

The buffer is the correct size that corresponds to an object of Element_Type. 
Much easier than figuring that out oneself.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-23 19:42 20% Ada.Storage_IO: applied example? Yannick Duchêne (Hibou57)
@ 2012-10-23 20:28  9% ` Dmitry A. Kazakov
  2012-10-23 20:56  8%   ` Yannick Duchêne (Hibou57)
                     ` (2 more replies)
  0 siblings, 3 replies; 31+ results
From: Dmitry A. Kazakov @ 2012-10-23 20:28 UTC (permalink / raw)


On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:

> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.

It looks useless at first glance. The buffer size is fixed and
implementation defined(!). Why would anybody use that rather than plain
array?

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



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-24 11:51  9%           ` Yannick Duchêne (Hibou57)
  2012-10-24 12:27  9%             ` Dmitry A. Kazakov
@ 2012-10-24 14:03 18%             ` Georg Bauhaus
  1 sibling, 0 replies; 31+ results
From: Georg Bauhaus @ 2012-10-24 14:03 UTC (permalink / raw)


On 24.10.12 13:51, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>>
>>> See AARM A.9(1.a):
>>> Reason: This package exists to allow the portable construction of
>>> user-defined direct-access-oriented input-output packages.
>>
>>    portable construction of X /= construction of portable X
>>
>> The package cannot be used to write files in a way that an application
>> compiled by one compiler X1 under OS Y1 could write a file readable for
>> compiler X2 under OS Y2.
>>
>> In order to be portable they should have defined the exact representation
>> of the object in the file. Yes, nobody would do that, but then they should
>> not include useless packages into the standard either.
> 
> What about private persistent storage?
> 

If traditional Ada I/O is good for your Ada program, you
can use Storage_IO in conventional algorithms this way. The
setup can employ static polymorphism that allows selecting
instances of Storage_IO or Direct_IO as needed.
Either at startup or later.

<rant>
The solution, using the egregious generic mechanisms of Ada,
will suffer from all the advantages of lack of an unused
tagged parameter.

The whole approach of stating requirements as generic formals
suffers from good opportunities for compilers to perform
optimization.

It suffers from the fact that stored internal program
data is not being stored in an ISO-approved form ready for
inspection by non-generic programs of an unrelated make
and purpose.

It also suffers from the problem that it still cannot make
the external world an Ada object, which could mollify the
previously argued flaw.

It suffers from lack of opportunities to control I/O of
octets algorithmically, thus preventing emulation of nice
per-program Storage_IO objects in DIY fashion.

It also suffers from not being a silver bullet.

But other than that ...</rant>

with Ada.Direct_IO;
with Ada.Storage_IO;
with Ada.Command_Line;  use Ada.Command_Line;

procedure Lookahead is
   use Ada;

   type Sentence (Length : Positive := 100) is record
      Text : Wide_String (1 .. 100);
   end record;

   subtype Name is Wide_String (1 .. 20);

   type Big is record   -- objects that will be processed
      First, Last : Name;
      Age : Natural;
      Motto : Sentence;
   end record;

   generic
      with procedure Store_Single_Item (Item : in Big);
      with procedure Fetch_Single_Item (Item : out Big);
   procedure Process_Records;

   procedure Process_Records is separate;
begin
   if Natural'Value (Argument(1)) = 0 then
      declare
         package Volatile is
            procedure Store (Item : in Big);
            procedure Fetch (Item : out Big);
         end Volatile;
         package body Volatile is
            package Undo_Buffer is new Storage_IO (Big);
            Storage : Undo_Buffer.Buffer_Type;
            procedure Fetch (Item : out Big) is
            begin
               Undo_Buffer.Read (Storage, Item);
            end Fetch;
            procedure Store (Item : in Big) is
            begin
               Undo_Buffer.Write (Storage, Item);
            end Store;
         end Volatile;
         procedure Run is new Process_Records
           (Store_Single_Item => Volatile.Store,
            Fetch_Single_Item => Volatile.Fetch);
      begin
         Run;
      end;
   else
      declare
         package Permanent is
            procedure Store (Item : in Big);
            procedure Fetch (Item : out Big);
         end Permanent;
         package body Permanent is
            package Undo_Buffer is new Direct_IO (Big);
            Storage : Undo_Buffer.File_Type;
            procedure Fetch (Item : out Big) is
            begin
               Undo_Buffer.Read (Storage, Item);
            end Fetch;
            procedure Store (Item : in Big) is
            begin
               Undo_Buffer.Write (Storage, Item);
            end Store;
            use Undo_Buffer;
         begin
            open (storage, Inout_File, "item.sto");
         end Permanent;
         procedure Run is new Process_Records
           (Store_Single_Item => Permanent.Store,
            Fetch_Single_Item => Permanent.Fetch);
      begin
         Run;
      end;
   end if;

end Lookahead;

separate (Lookahead)
procedure Process_Records is
   package Rec_IO is new Direct_IO (Big); use Rec_IO;
   Current: Big := (Age => Natural'Last, others => <>);
   input : File_Type;
   output : File_Type;
begin
   open (input, In_File, "records.all");
   open (output, Out_File, "records.flt");
   loop
      Store_Single_Item (Current);
      Read (input, current);
      -- ... filter based on pairs ...
         write (output, current);
   end loop;
end Process_Records;




^ permalink raw reply	[relevance 18%]

* Re: Ada.Storage_IO: applied example?
  2012-10-24 11:51  9%           ` Yannick Duchêne (Hibou57)
@ 2012-10-24 12:27  9%             ` Dmitry A. Kazakov
  2012-10-24 14:03 18%             ` Georg Bauhaus
  1 sibling, 0 replies; 31+ results
From: Dmitry A. Kazakov @ 2012-10-24 12:27 UTC (permalink / raw)


On Wed, 24 Oct 2012 13:51:21 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>>
>>> See AARM A.9(1.a):
>>> Reason: This package exists to allow the portable construction of
>>> user-defined direct-access-oriented input-output packages.
>>
>>    portable construction of X /= construction of portable X
>>
>> The package cannot be used to write files in a way that an application
>> compiled by one compiler X1 under OS Y1 could write a file readable for
>> compiler X2 under OS Y2.
>>
>> In order to be portable they should have defined the exact representation
>> of the object in the file. Yes, nobody would do that, but then they  
>> should not include useless packages into the standard either.
> 
> What about private persistent storage?

   X1 = X2 and Y1 = Y2

What are chances of having this? And what are chances that a user would
mistakenly use the package when X1 /= X2 or Y1 /= Y2?

Specifically to persistent storage, you would need to be able to debug it,
reinterpret using some independent tools, have redundancy and additional
checks on top, be able to store indefinite objects, be independent on the
medium etc. A *generic* package parametrized by a private type with no
representation defined is a non-starter.

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



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-24  9:49  7%       ` AdaMagica
@ 2012-10-24 10:28  8%         ` Dmitry A. Kazakov
  2012-10-24 11:51  9%           ` Yannick Duchêne (Hibou57)
  0 siblings, 1 reply; 31+ results
From: Dmitry A. Kazakov @ 2012-10-24 10:28 UTC (permalink / raw)


On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:

> See AARM A.9(1.a):
> Reason: This package exists to allow the portable construction of
> user-defined direct-access-oriented input-output packages.

   portable construction of X /= construction of portable X

The package cannot be used to write files in a way that an application
compiled by one compiler X1 under OS Y1 could write a file readable for
compiler X2 under OS Y2.

In order to be portable they should have defined the exact representation
of the object in the file. Yes, nobody would do that, but then they should
not include useless packages into the standard either.

> On Wednesday, October 24, 2012 9:34:32 AM UTC+2, Dmitry A. Kazakov wrote:
>> data at. Furthermore the generic parameter should have been declared as:
>>    type Element_Type (<>) is private.
> 
> See A.9(10.a):
> Reason: As with Direct_IO, the Element_Type formal of Storage_IO does not
> have an unknown_discriminant_part so that there is a well-defined upper
> bound on the size of the buffer needed to hold the content of an object of
> the formal subtype (i.e. Buffer_Size).

The reason why Direct_IO must have an upper bound is to allow accessing
records randomly without an excessive (in 70's it was excessive) overhead
of indexing them. This simply does not apply to Storage_IO, which has just
one "record."

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



^ permalink raw reply	[relevance 8%]

* Re: Ada.Storage_IO: applied example?
  2012-10-24 10:28  8%         ` Dmitry A. Kazakov
@ 2012-10-24 11:51  9%           ` Yannick Duchêne (Hibou57)
  2012-10-24 12:27  9%             ` Dmitry A. Kazakov
  2012-10-24 14:03 18%             ` Georg Bauhaus
  0 siblings, 2 replies; 31+ results
From: Yannick Duchêne (Hibou57) @ 2012-10-24 11:51 UTC (permalink / raw)


Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>
>> See AARM A.9(1.a):
>> Reason: This package exists to allow the portable construction of
>> user-defined direct-access-oriented input-output packages.
>
>    portable construction of X /= construction of portable X
>
> The package cannot be used to write files in a way that an application
> compiled by one compiler X1 under OS Y1 could write a file readable for
> compiler X2 under OS Y2.
>
> In order to be portable they should have defined the exact representation
> of the object in the file. Yes, nobody would do that, but then they  
> should
> not include useless packages into the standard either.

What about private persistent storage?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-24  5:03  9%   ` J-P. Rosen
@ 2012-10-24  7:34  9%     ` Dmitry A. Kazakov
  2012-10-24  9:49  7%       ` AdaMagica
  0 siblings, 1 reply; 31+ results
From: Dmitry A. Kazakov @ 2012-10-24  7:34 UTC (permalink / raw)


On Wed, 24 Oct 2012 07:03:43 +0200, J-P. Rosen wrote:

> Le 23/10/2012 22:28, Dmitry A. Kazakov a �crit :
>> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
>> 
>>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>> 
>> It looks useless at first glance. The buffer size is fixed and
>> implementation defined(!). Why would anybody use that rather than plain
>> array?
>> 
> Imagine you want to implement a binary IO package. On one side you have
> high level data type, on the other side system files that are just
> blocks of bytes. Storage_IO allows you to bridge this gap (at least
> that's my understanding).

In that case the package should rather define conversions to and from
Storage_Array, better as in-place operations with a position to get/put
data at. Furthermore the generic parameter should have been declared as:

   type Element_Type (<>) is private.

And, of course, implementation-defined I/O is a bad idea anyway in modern
times of interoperability. (This also applies to Direct_IO and
Sequential_IO, which are remnants of late 70's.)

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



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-23 20:28  9% ` Dmitry A. Kazakov
@ 2012-10-23 20:56  8%   ` Yannick Duchêne (Hibou57)
  2012-10-23 21:21  7%     ` Adam Beneschan
  2012-10-23 21:02  9%   ` Jeffrey Carter
  2012-10-24  5:03  9%   ` J-P. Rosen
  2 siblings, 1 reply; 31+ results
From: Yannick Duchêne (Hibou57) @ 2012-10-23 20:56 UTC (permalink / raw)


Le Tue, 23 Oct 2012 22:28:34 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>
> It looks useless at first glance.
Yes, indeed, it looks, lol. That's precisely the reason why I opened this  
topic. I would hardly believe something that usefulness belongs to the  
standard packages, so I guess I am missing something, and would like to  
learn what it is. Is this a kind of holder container?

> The buffer size is fixed and implementation defined(!).
It's implementation defined, but not “randomly”: the size correspond to  
the count of storage elements (it self, implementation defined) required  
to store an instance of the element type which is the parameter of the  
generic package. That's implementation defined, but predictable.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University



^ permalink raw reply	[relevance 8%]

* Re: Ada.Storage_IO: applied example?
  2012-10-24  7:34  9%     ` Dmitry A. Kazakov
@ 2012-10-24  9:49  7%       ` AdaMagica
  2012-10-24 10:28  8%         ` Dmitry A. Kazakov
  0 siblings, 1 reply; 31+ results
From: AdaMagica @ 2012-10-24  9:49 UTC (permalink / raw)


See AARM A.9(1.a):
Reason: This package exists to allow the portable construction of user-defined direct-access-oriented input-output packages. The Write procedure writes a value of type Element_Type into a Storage_Array of size Buffer_Size, flattening out any implicit levels of indirection used in the representation of the type. The Read procedure reads a value of type Element_Type from the buffer, reconstructing any implicit levels of indirection used in the representation of the type. It also properly initializes any type tags that appear within the value, presuming that the buffer was written by a different program and that tag values for the “same” type might vary from one executable to another.

On Wednesday, October 24, 2012 9:34:32 AM UTC+2, Dmitry A. Kazakov wrote:
> data at. Furthermore the generic parameter should have been declared as:
>    type Element_Type (<>) is private.

See A.9(10.a):
Reason: As with Direct_IO, the Element_Type formal of Storage_IO does not have an unknown_discriminant_part so that there is a well-defined upper bound on the size of the buffer needed to hold the content of an object of the formal subtype (i.e. Buffer_Size). If there are no implicit levels of indirection, Buffer_Size will typically equal:
   (Element_Type'Size + System.Storage_Unit - 1) / System.Storage_Unit



^ permalink raw reply	[relevance 7%]

* Re: Ada.Storage_IO: applied example?
  2012-10-23 21:02  9%   ` Jeffrey Carter
@ 2012-10-24  7:20  9%     ` Dmitry A. Kazakov
  0 siblings, 0 replies; 31+ results
From: Dmitry A. Kazakov @ 2012-10-24  7:20 UTC (permalink / raw)


On Tue, 23 Oct 2012 14:02:43 -0700, Jeffrey Carter wrote:

> On 10/23/2012 01:28 PM, Dmitry A. Kazakov wrote:
>> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
>>
>>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
>>
>> It looks useless at first glance. The buffer size is fixed and
>> implementation defined(!). Why would anybody use that rather than plain
>> array?
> 
> The buffer is the correct size that corresponds to an object of Element_Type. 
> Much easier than figuring that out oneself.

Less than useless, as the name (I/O) gives a (false) impression that one
could read/write more than just one item into the thing.

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



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-23 20:28  9% ` Dmitry A. Kazakov
  2012-10-23 20:56  8%   ` Yannick Duchêne (Hibou57)
  2012-10-23 21:02  9%   ` Jeffrey Carter
@ 2012-10-24  5:03  9%   ` J-P. Rosen
  2012-10-24  7:34  9%     ` Dmitry A. Kazakov
  2 siblings, 1 reply; 31+ results
From: J-P. Rosen @ 2012-10-24  5:03 UTC (permalink / raw)


Le 23/10/2012 22:28, Dmitry A. Kazakov a �crit :
> On Tue, 23 Oct 2012 21:42:43 +0200, Yannick Duch�ne (Hibou57) wrote:
> 
>> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
> 
> It looks useless at first glance. The buffer size is fixed and
> implementation defined(!). Why would anybody use that rather than plain
> array?
> 
Imagine you want to implement a binary IO package. On one side you have
high level data type, on the other side system files that are just
blocks of bytes. Storage_IO allows you to bridge this gap (at least
that's my understanding).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr



^ permalink raw reply	[relevance 9%]

* Re: Ada.Storage_IO: applied example?
  2012-10-23 20:56  8%   ` Yannick Duchêne (Hibou57)
@ 2012-10-23 21:21  7%     ` Adam Beneschan
  0 siblings, 0 replies; 31+ results
From: Adam Beneschan @ 2012-10-23 21:21 UTC (permalink / raw)


On Tuesday, October 23, 2012 1:57:02 PM UTC-7, Hibou57 (Yannick Duchêne) wrote:
> Le Tue, 23 Oct 2012 22:28:34 +0200, Dmitry A. Kazakov  

> >> I'm seeking for a tiny use case showing `Ada.Storage_IO` in action.
> > It looks useless at first glance.
> 
> Yes, indeed, it looks, lol. That's precisely the reason why I opened this  
> topic. I would hardly believe something that usefulness belongs to the  
> standard packages, so I guess I am missing something, and would like to  
> learn what it is. Is this a kind of holder container?
> 
> > The buffer size is fixed and implementation defined(!).
> 
> It's implementation defined, but not “randomly”: the size correspond to  
> the count of storage elements (it self, implementation defined) required  
> to store an instance of the element type which is the parameter of the  
> generic package. That's implementation defined, but predictable.

Looking at the AARM, it appears that the main reason this might be useful is you've defined a record type that contains a hidden pointer (i.e. a pointer that the Ada implementation sets up, not a subcomponent of an access type).  In that case, the buffer contains the "flattened" version of the data.  E.g.

   type Rec is record
     S : String (1 .. Name_Size);
     ... other components
   end record;

where Name_Size is non-static object (i.e. the value can't be determined at compile time).  Some implementations (but not GNAT, I believe) would store S as a pointer, rather than fool around with Rec objects whose size isn't known at compile time, and possibly components whose location in the record isn't known at compile time.  In this case, you couldn't rely on Rec'Size (or Rec'Size / System.Storage_Unit) to be large enough to contain all the data; I think that's the kind of case where the language designers thought this would be useful, because you could write code that would work with any Ada implementation.  Still, you should be able to accomplish the same thing using the stream features of Ada, and I think that would be preferable.

                           -- Adam



^ permalink raw reply	[relevance 7%]

* Ada.Storage_IO: applied example?
@ 2012-10-23 19:42 20% Yannick Duchêne (Hibou57)
  2012-10-23 20:28  9% ` Dmitry A. Kazakov
  0 siblings, 1 reply; 31+ results
From: Yannick Duchêne (Hibou57) @ 2012-10-23 19:42 UTC (permalink / raw)


Hi all the people,


I'm seeking for a tiny use case showing `Ada.Storage_IO` in action. I also  
believe the topic is worth for many people, beginners or not, as this is  
the kind of stuff so typical of Ada. I always liked the clean distinction  
Ada makes between streams and files. Looking for some reminder about it in  
the RM, I just noticed this `Ada.Storage_IO` I've never noticed before.,  
but feel surprised the buffer always contains a single element; thus the  
question. The RM makes a reference from there to `Ada.Direct_IO`, but the  
latter does not reciprocally mention the former.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University



^ permalink raw reply	[relevance 20%]

* Re: Ada.Storage_IO. Anyone use it?
       [not found]     <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com>
  2012-06-09  8:36 19% ` Dmitry A. Kazakov
@ 2012-06-09 14:24  8% ` anon
  1 sibling, 0 replies; 31+ results
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	[relevance 8%]

* Re: Ada.Storage_IO. Anyone use it?
  2012-06-09  8:36 19% ` Dmitry A. Kazakov
@ 2012-06-09 14:09 21%   ` Georg Bauhaus
  0 siblings, 0 replies; 31+ results
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	[relevance 21%]

* Re: Ada.Storage_IO. Anyone use it?
       [not found]     <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com>
@ 2012-06-09  8:36 19% ` Dmitry A. Kazakov
  2012-06-09 14:09 21%   ` Georg Bauhaus
  2012-06-09 14:24  8% ` anon
  1 sibling, 1 reply; 31+ results
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	[relevance 19%]

* Ada.Storage_IO. Anyone use it?
@ 2012-06-09  8:18 19% Micronian Coder
  0 siblings, 0 replies; 31+ results
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	[relevance 19%]

* Re: How do I write directly to a memory address?
  @ 2011-02-03 18:07  8% ` Jeffrey Carter
  0 siblings, 0 replies; 31+ results
From: Jeffrey Carter @ 2011-02-03 18:07 UTC (permalink / raw)


On 02/03/2011 01:08 AM, mockturtle wrote:
>
> I do not have any experience about this part of Ada, but maybe I can give you
> a "pointer" to some bootstrapping information.  Maybe you could want to use
> an attribute representation  clause for Vidmem'Address (see Section 13.3 of
> the RM) . With some improvisation, I would write something like
>
> type Vidmem_Array is array (natural range<>) of Character; Vidmem :
> Vidmem_Array (0 .. Max_Size);
>
> for Vidmem'Address use 16#000B_8000#;

An address clause is the usual approach. If one is going to write to such 
memory, one probably doesn't care what the Ada runtime might do to initialize 
it, but if one is planning to read predefined information stored there, one 
probably wants to prevent any initialization through a pragma Import:

pragma Import (Ada, Vidmem);

System.Address is an implementation-defined type, and an address clause takes a 
value of that type. A universal integer may or may not be acceptable. Any such 
code is not portable.

Other possibilities include Ada.Storage_IO (ARM A.9) and 
System.Address_To_Access_Conversions (ARM 13.7.2). Masochists (such as those who 
use C-family languages by choice) might want to use address arithmetic, found in 
System.Storage_Elements (ARM 13.7.1).

Note that the quoted C code will happily read from memory not part of message 
and write to memory not part of vidmem; Ada will not.

-- 
Jeff Carter
"How'd you like to hide the egg and gurgitate
a few saucers of mocha java?"
Never Give a Sucker an Even Break
101



^ permalink raw reply	[relevance 8%]

* Re: Separate type for byte arrays
  @ 2006-05-04 18:15 11% ` Jeffrey R. Carter
  0 siblings, 0 replies; 31+ results
From: Jeffrey R. Carter @ 2006-05-04 18:15 UTC (permalink / raw)


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



^ permalink raw reply	[relevance 11%]

* Re: sizeof in ADA
  @ 2005-08-05 16:00  8% ` Jeffrey Carter
  0 siblings, 0 replies; 31+ results
From: Jeffrey Carter @ 2005-08-05 16:00 UTC (permalink / raw)


sisi.ard@laposte.net wrote:
> I would like to know how to write an equivolent of the C function
> "sizeof "

There is the 'Max_Size_In_Storage_Units attribute, which may be what you 
want.

The 'Size attribute gives the size in bits of a subtype or object. For a 
stand-alone object, 'Size is usually a multiple of System.Storage_Unit, 
which is the number of bits in a storage unit (8 on a byte-oriented 
processor).

Note that 'Size can differ between a subtype and an object. For many 
platforms and compilers:

Boolean'Size = 1
Natural'Size = 31

B : Boolean;
N : Natural;

B'Size = 8;
N'Size = 32

So Object'Size / System.Storage_Unit will give you the correct value for 
an object. It may be better to base your values on the object than on 
the subtype.

Another way is to instantiate Ada.Storage_IO for the subtype. This then 
gives you the constant Buffer_Size, which is what you want. This is 
rather a heavyweight solution, however.

-- 
Jeffrey Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail
E-mail: jeffrey_r_carter-nr [commercial-at]
         raytheon [period | full stop] com



^ permalink raw reply	[relevance 8%]

* Re: Unchecked_Conversion and alignment
    2003-01-21 19:41  9% ` Jeffrey Carter
@ 2003-01-21 21:15  0% ` Victor Porton
  1 sibling, 0 replies; 31+ results
From: Victor Porton @ 2003-01-21 21:15 UTC (permalink / raw)


In article <3E2DA280.70905@acm.org>,
	Jeffrey Carter <jrcarter@acm.org> writes:
> Victor Porton wrote:
>> 
>> So, it appears impossible to keep several objects of arbitrary types in 
>> an array of an array of System.Storage_Elements.Storage_Array (as these 
>> alignments are not necessarily equal).
> 
> You can probably get what you want using Ada.Storage_IO.

Absolutely no: firstly, I need objects of different types, not a 
homogeneous array; secondly, I need accesses to the elements which 
Storage_IO does not provide.



^ permalink raw reply	[relevance 0%]

* Re: Unchecked_Conversion and alignment
  @ 2003-01-21 19:41  9% ` Jeffrey Carter
  2003-01-21 21:15  0% ` Victor Porton
  1 sibling, 0 replies; 31+ results
From: Jeffrey Carter @ 2003-01-21 19:41 UTC (permalink / raw)


Victor Porton wrote:
> 
> So, it appears impossible to keep several objects of arbitrary types in 
> an array of an array of System.Storage_Elements.Storage_Array (as these 
> alignments are not necessarily equal).

You can probably get what you want using Ada.Storage_IO.

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall




^ permalink raw reply	[relevance 9%]

* Re: Elimination of "use" clauses
  @ 1999-07-12  0:00  9%                 ` Ted Dennison
  0 siblings, 0 replies; 31+ results
From: Ted Dennison @ 1999-07-12  0:00 UTC (permalink / raw)


In article <7mdml7$vo4$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> My preferred approach would be to forbid any user packages
> from duplicating the names used in the RM in Annex A and
> other standard packages, unless there is a very definite
> methodological reason for the duplication (e.g. defining
> a Put procedure for additional types).

That's a pretty hefty set of useful names you are putting off-limits!
For instance:
  "Move", "Index", "Count", "Insert", "Delete" (Ada.Strings.Fixed)
  "Split" (Ada.Calendar)
  "Read", "Write" (Ada.Storage_IO, Ada.Streams)
  "Create", "Reset", "Name" (Ada.Text_IO)
  "Initialize", "Adjust" (Ada.Finalization)
  "Size" (Ada.Direct_IO)

Looking over this list, its interesting how much more sense each makes
at first glance when given the context of its package name...

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.




^ permalink raw reply	[relevance 9%]

* Re: CRC in Ada?
  @ 1997-03-10  0:00  7%   ` David Brown
  0 siblings, 0 replies; 31+ results
From: David Brown @ 1997-03-10  0:00 UTC (permalink / raw)



dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> The proper way to read this file in Ada 95 is to use Stream_IO into
> a stream element buffer. The imagined "prime number" restriction
> does not exist, and in practice this should be highly efficient.

Ok, so I am reading the file data into a stream element buffer
(Stream_Element_Array).  My file, however, really consists of some
small objects (16 bit signed integers).  What is the "proper" way to
get these integers out of this buffer?  I want there to be as little
copying of these numbers as possible.  Here are some solutions I've
come up with:

1.  Have code to extract and insert my objects out of a stream element
    array.  These routines could be inlined and the access would end
    up fast.  However, they would be cumbersome to call because the
    item wouldn't quite be an array.

2.  Use for Foo'Address clauses or address to access conversions to
    alias an array of my data on top of the stream element buffer.
    Aside from the general feeling of grossness about this, I have
    heard mentioned on this group that this is not the proper way of
    aliasing two data items.  Is there a "proper" way of doing this?

3.  Use Ada.Storage_IO to convert the buffer into a buffer of my
    data.  This will cause a copy.

4.  Just do my I/O by calling my underlying operating system calls.
    This would probably be most efficient.  With the GNAT runtime, the
    stream IO read and write just call fread which on my OS doesn't do
    a copy if the buffer is large enough.  In other words, if I could
    somehow avoid the copy in Ada, the Stream IO code would be
    efficient enough.

Dave Brown
dbrown@vigra.com




^ permalink raw reply	[relevance 7%]

Results 1-31 of 31 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1997-03-02  0:00     CRC in Ada? Dr. John B. Matthews
1997-03-05  0:00     ` Larry Kilgallen
1997-03-10  0:00  7%   ` David Brown
1999-07-01  0:00     Elimination of "use" clauses Dr. Neil C. Audsley
1999-07-02  0:00     ` Robert Dewar
1999-07-02  0:00       ` Samuel T. Harris
1999-07-02  0:00         ` Robert Dewar
     [not found]           ` <7ltl2q$mog$1@nnrp1.deja.com>
1999-07-08  0:00             ` Michael F. Yoder
1999-07-09  0:00               ` Robert Dewar
1999-07-09  0:00                 ` Dale Stanbrough
1999-07-12  0:00                   ` Robert Dewar
1999-07-12  0:00  9%                 ` Ted Dennison
2003-01-21  7:01     Unchecked_Conversion and alignment Victor Porton
2003-01-21 19:41  9% ` Jeffrey Carter
2003-01-21 21:15  0% ` Victor Porton
2005-08-05 14:42     sizeof in ADA sisi.ard
2005-08-05 16:00  8% ` Jeffrey Carter
2006-05-04 13:35     Separate type for byte arrays Florian Weimer
2006-05-04 18:15 11% ` Jeffrey R. Carter
2011-02-03  8:08     How do I write directly to a memory address? mockturtle
2011-02-03 18:07  8% ` Jeffrey Carter
2012-06-09  8:18 19% Ada.Storage_IO. Anyone use it? Micronian Coder
     [not found]     <a09e06d1-716f-4e3b-926b-55144f20d35a@googlegroups.com>
2012-06-09  8:36 19% ` Dmitry A. Kazakov
2012-06-09 14:09 21%   ` Georg Bauhaus
2012-06-09 14:24  8% ` anon
2012-10-23 19:42 20% Ada.Storage_IO: applied example? Yannick Duchêne (Hibou57)
2012-10-23 20:28  9% ` Dmitry A. Kazakov
2012-10-23 20:56  8%   ` Yannick Duchêne (Hibou57)
2012-10-23 21:21  7%     ` Adam Beneschan
2012-10-23 21:02  9%   ` Jeffrey Carter
2012-10-24  7:20  9%     ` Dmitry A. Kazakov
2012-10-24  5:03  9%   ` J-P. Rosen
2012-10-24  7:34  9%     ` Dmitry A. Kazakov
2012-10-24  9:49  7%       ` AdaMagica
2012-10-24 10:28  8%         ` Dmitry A. Kazakov
2012-10-24 11:51  9%           ` Yannick Duchêne (Hibou57)
2012-10-24 12:27  9%             ` Dmitry A. Kazakov
2012-10-24 14:03 18%             ` Georg Bauhaus
2013-10-30 23:31 11% FNV-1 sbelmont700
2017-01-24 13:12     Dynamic type system for Ada Victor Porton
2017-01-24 13:44     ` Dmitry A. Kazakov
2017-01-24 13:58       ` Victor Porton
2017-01-24 18:07  9%     ` Jeffrey R. Carter
2020-07-04 17:00     General circular buffer example not tied to any specific type Daniel
2020-07-04 17:25     ` Dmitry A. Kazakov
2020-07-05  9:37       ` Simon Wright
2020-07-05  9:52         ` Simon Wright
2020-07-05 13:25  9%       ` Jeffrey R. Carter
2020-07-05 15:36  0%         ` Simon Wright
2020-07-05 18:46  0%           ` Dmitry A. Kazakov
2020-07-05 19:51  0%             ` Simon Wright
2020-07-06  8:11  0%         ` Simon Wright

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox