C to Ada : a piece of code

C to Ada : a piece of code

[Grave Xavier]

Hi,

Can somebody explain me a way to translate this C code to
Ada ? I just want to avoid using chained list for a vector
of double.

-------------------------
double *vect;
long size,i;

scanf("%ld",&size);
vect = (double *) calloc(size,sizeof(double));
for(i=0;i<size;i++)
   {vect[i] = ....;
   }
-------------------------

Thanks.

-- 
xavier@virgoa4.in2p3.fr

De chacun selon ses forces, a chacun selon ses besoins.

Re: C to Ada : a piece of code

[Robert A Duff]

In article <3231732C.2781@virgoa4.in2p3.fr>,
Grave Xavier  <xavier@virgoa4.in2p3.fr> wrote:
>Hi,
>
>Can somebody explain me a way to translate this C code to
>Ada ? I just want to avoid using chained list for a vector
>of double.
>
>-------------------------
>double *vect;
>long size,i;
>
>scanf("%ld",&size);
>vect = (double *) calloc(size,sizeof(double));
>for(i=0;i<size;i++)
>   {vect[i] = ....;
>   }
>-------------------------

type My_Float is digits 8; -- or whatever
type Vector is array(Positive range <>) of My_Float;
Size: Positive := ...;
V: Vector(1..Size);
...
for I in V'Range loop
    V(I) := ...;
end loop;

Or:

type Vector_Ptr is access Vector;
VP: Vector_Ptr := new Vector(1..Size);

----------------

- Bob

Re: C to Ada : a piece of code

[David C. Hoos, Sr.]

Hi,
Grave Xavier <xavier@virgoa4.in2p3.fr> wrote in article
<3231732C.2781@virgoa4.in2p3.fr>...
> Hi,
> 
> Can somebody explain me a way to translate this C code to
> Ada ? I just want to avoid using chained list for a vector
> of double.
> 
> -------------------------
> double *vect;
> long size,i;
> 
> scanf("%ld",&size);
> vect = (double *) calloc(size,sizeof(double));
> for(i=0;i<size;i++)
>    {vect[i] = ....;
>    }
> -------------------------
> 
> Thanks.
> 
> -- 
> xavier@virgoa4.in2p3.fr
> 
> De chacun selon ses forces, a chacun selon ses besoins.
> 

The file at the end of this message does waht you ask.  It is, however not
a faithful translation in one respect.  The C function scanf is notorious
for failing with invalid inputs.  The ada code shown here is tolerant of
user input errors, which the scanf code is not.

Hope this illustrates a few other useful Ada features, in addition to your
specific request.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

------ File xavier.adb begins ---------

with Text_IO;
procedure Xavier is
  Standard_Input    : Text_IO.FILE_TYPE;
  Temporary_String  : STRING (1 .. 256);
  The_Line_Length   : NATURAL;
  The_Vector_Length : NATURAL;
  type FLOAT_VECTOR_TYPE is array (INTEGER range <>) of LONG_FLOAT;
  type FLOAT_VECTOR_ACCESS_TYPE is access FLOAT_VECTOR_TYPE;
  The_Vector_Access : FLOAT_VECTOR_ACCESS_TYPE;
  package Long_Float_IO is new Text_IO.Float_IO (LONG_FLOAT);
begin
  loop
    Text_IO.Get_Line (
	  Item => Temporary_String,
        Last => The_Line_Length
        );
    begin
      if The_Line_Length > 0 then
        The_Vector_Length := NATURAL'VALUE (
            Temporary_String (1 .. The_Line_Length)
            );
      else
        The_Vector_Length := 0;
      end if;
      exit;
    exception
      when Constraint_Error | Numeric_Error =>
        Text_IO.Put_Line (
            """" &
            Temporary_String (1 .. The_Line_Length) &
            """ is not a valid integer value representation.  Re-enter"
            );
    end;
  end loop;
  The_Vector_Access := new FLOAT_VECTOR_TYPE' (
      (0 .. The_Vector_Length - 1 => 0.0)
      );
  for i in The_Vector_Access'RANGE loop
    The_Vector_Access (i) := LONG_FLOAT (i);
  end loop;

  for i in The_Vector_Access'RANGE loop
    Text_IO.Put (
        "The_Vector (" &
        INTEGER'IMAGE (i) &
        " ) => "
        ); 
        Long_Float_IO.Put (The_Vector_Access (i));
    Text_IO.New_Line;
    if i mod 5 = 4 then
      Text_IO.New_Line;
    end if;
  end loop;
end Xavier;

------ File xavier.adb ends ---------

Re: C to Ada : a piece of code

[Jon S Anthony]

In article <3231732C.2781@virgoa4.in2p3.fr> Grave Xavier <xavier@virgoa4.in2p3.fr> writes:

> Can somebody explain me a way to translate this C code to
> Ada ? I just want to avoid using chained list for a vector
> of double.           ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> -------------------------
> double *vect;
> long size,i;
> 
> scanf("%ld",&size);
> vect = (double *) calloc(size,sizeof(double));
> for(i=0;i<size;i++)
>    {vect[i] = ....;
>    }

    type Vec_Array_Type is array ( Positive range <> ) of Long_Float;
    Size : Natural;
...
    Integer_Text_IO.Get(Size);
    declare
        Vec : Vec_Array_Type(1..Size); -- No malloc, no linked list.
    begin
        for I in Vec'Range loop
            Vec(i) := ....;
        end loop;
    end;


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C to Ada : a piece of code

[David C. Hoos, Sr.]

Jon S Anthony <jsa@alexandria> wrote in article
<JSA.96Sep7205717@alexandria>...
> In article <3231732C.2781@virgoa4.in2p3.fr> Grave Xavier
<xavier@virgoa4.in2p3.fr> writes:
> 
>     type Vec_Array_Type is array ( Positive range <> ) of Long_Float;
>     Size : Natural;
> ...
>     Integer_Text_IO.Get(Size);
>     declare
>         Vec : Vec_Array_Type(1..Size); -- No malloc, no linked list.
>     begin
>         for I in Vec'Range loop
>             Vec(i) := ....;
>         end loop;
>     end;
> /Jon
Hi Jon,
Two things about your solution are not direct translations, viz.:
    1.  The declare block is not equivalent to calloc or malloc, inasmuch
as the array goes out of scope when exiting the block.  Your declaration
would be equivalent to alloca.  Xavier doesn't say whether he intends to
pass this pointer off to somewhere that's out of scope, in which case the
malloc or new is required.
    2.  Xavier specified a 0-based index for the array, whereas your is
1-based.  I know that C gives no choice in the matter, but Ada does, and
many times the 0-based index is more mathematically convenient, depending
on the application.

Refer to my previous post for a suggested solution.

In my original post, I had intended to ask Xavier why he went to the
expense of calloc, when malloc would be cheaper, and he was going to assign
all values in his loop.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: C to Ada : a piece of code

[nasser]

In article <01bb9d61$537fe5e0$2b8371a5@dhoossr.iquest.com>, "David says...

...snip..

>    2.  Xavier specified a 0-based index for the array, whereas your is
>1-based.  I know that C gives no choice in the matter, but Ada does, and
>many times the 0-based index is more mathematically convenient, depending
>on the application.
>

One of the things I dislike most about C/C++ is that arrays start from 
0. Arrays that start from 1 are much easier to work with and more
natural.  IMHO.

Nasser
--
Nasser Abbasi. C/C++/Ada Solaris. Perkin Elmer - Applied BioSystem division. 
email:  nasser@apldbio.com   MSEE, MSCS, MSCE, Fide chess master (FM).

"640K ought to be enough for anybody."   Bill Gates, 1981

"I think there is a world market for maybe five computers." 
Thomas Watson,  chairman of IBM, 1943

"There is no reason anyone would want a computer in their home." 
Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977

"This 'telephone' has too many shortcomings to be seriously considered
as a means of communication."   Western Union internal memo, 1876.

"Heavier-than-air flying machines are impossible."
Lord Kelvin, president, Royal Society, 1895.

"Everything that can be invented has been invented."
Charles H. Duell, Commissioner, U.S. Office of Patents, 1899.

Re: C to Ada : a piece of code

[Robert Dewar]

"The trade off, (in those frequent cases where 0-based indexing is more
appropriate) is the one-time ugliness of the allocation, vs. the every time
ugliness of the references which need something like Vect'FIRST subtracted
during index computation."

In most cases, this extra subtraction ends up being essentially free since
it is always pulled out of loops. In any case, it is perfectly possible
to have implementations that avoid this subtraction all the time by using
virtual origins.

Re: C to Ada : a piece of code

[John G. Volan]

David C. Hoos, Sr. wrote:
> 
> The trade off, (in those frequent cases where 0-based indexing is more
> appropriate) is the one-time ugliness of the allocation, vs. the every time
> ugliness of the references which need something like Vect'FIRST subtracted
> during index computation.

Not so fast, David! First of all, that's an under-the-hood
implementation issue.
Second of all, what you describe is only one possible implementation of
array index computation, namely:

    item_address := first_item_address + (index - first_index) *
item_size

    [where item_size = size of an item in storage units]

But there is at least one other possible scheme (exploited by the GNAT
compiler,
I believe), which avoids that subtraction:

    item_address := zeroeth_item_address + index * item_size

    [where zeroeth_item_address = first_item_address - first_index *
item_size]

In other words, you pretend that the array extends beyond its lower end
and hypothetically determine where the "zeroeth" item would be. You do
this just once, and thereafter compute all your array offsets directly
from your array indexes, without any subtraction, using this "zeroeth"
address as the basis. As always, there's no risk of tromping on memory
outside the array, because Ada's index constraints require index >=
first_index.
 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "John_Volan@syspac.com",
   Employer => "S.A.I.C.",   Work_Email => "John_Volan@dayton.saic.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " &
     "them is totally erroneous...or is that a bounded error now? :-)");
------------------------------------------------------------------------

Re: C to Ada : a piece of code

[Jon S Anthony]

In article <01bb9d61$537fe5e0$2b8371a5@dhoossr.iquest.com> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> Jon S Anthony <jsa@alexandria> wrote in article
> <JSA.96Sep7205717@alexandria>...
> > In article <3231732C.2781@virgoa4.in2p3.fr> Grave Xavier
> <xavier@virgoa4.in2p3.fr> writes:
> > 
> >     type Vec_Array_Type is array ( Positive range <> ) of Long_Float;
> >     Size : Natural;
> > ...
> >     Integer_Text_IO.Get(Size);
> >     declare
> >         Vec : Vec_Array_Type(1..Size); -- No malloc, no linked list.
> >     begin
> >         for I in Vec'Range loop
> >             Vec(i) := ....;
> >         end loop;
> >     end;
> > /Jon
> Hi Jon,
> Two things about your solution are not direct translations, viz.:
>     1.  The declare block is not equivalent to calloc or malloc, inasmuch
> as the array goes out of scope when exiting the block.  Your declaration
> would be equivalent to alloca.  Xavier doesn't say whether he intends to
> pass this pointer off to somewhere that's out of scope, in which case the
> malloc or new is required.

Well, sure.  I guess I should have included an ellipsis after the end
loop to show the rest of whatever you might want to do.  Also, there's
no reason why you couldn't just eliminate the declare block by means
of a subprogram.  As for not using malloc in this case, I see that as
a real good thing - no memory management to deal with.  As far as
calloc, you can just add an initializer (for unknown reasons since he
just sets all the values anyway).  And you can always pass such an
array around via parameters or function returns - again no need for
the allocator.


>     2.  Xavier specified a 0-based index for the array, whereas your
> is 1-based.  I know that C gives no choice in the matter, but Ada
> does, and many times the 0-based index is more mathematically
> convenient, depending on the application.

Shrug.  It uglifies the dynamic array allocation (needing a -1).  He
said _equivalent_ Ada, not "identical" word for word translation.  In
fact, an identical word for word translation of this particular case
is just bad Ada.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C to Ada : a piece of code

[David C. Hoos, Sr.]

Jon S Anthony <jsa@alexandria> wrote in article
<JSA.96Sep8202531@alexandria>...
> In article <01bb9d61$537fe5e0$2b8371a5@dhoossr.iquest.com> "David C.
Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
> Well, sure.  I guess I should have included an ellipsis after the end
> loop to show the rest of whatever you might want to do.  Also, there's
> no reason why you couldn't just eliminate the declare block by means
> of a subprogram.  As for not using malloc in this case, I see that as
> a real good thing - no memory management to deal with.  As far as
> calloc, you can just add an initializer (for unknown reasons since he
> just sets all the values anyway).  And you can always pass such an
> array around via parameters or function returns - again no need for
> the allocator.
Please explain to me how, (since the size of the array required is acquired
through standard input) if dynamic memory allocation is not used, you're
going to acquire static memory of the specified size, to which access can
be safely passed without it's going out of scope.  In fact, gnat has gotten
smarter than, say, VADS, in this regard, in that it will tell you when
you're passing access to memory that would be out of scope.

> Shrug.  It uglifies the dynamic array allocation (needing a -1).  He
> said _equivalent_ Ada, not "identical" word for word translation.  In
> fact, an identical word for word translation of this particular case
> is just bad Ada.

The trade off, (in those frequent cases where 0-based indexing is more
appropriate) is the one-time ugliness of the allocation, vs. the every time
ugliness of the references which need something like Vect'FIRST subtracted
during index computation.

-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

> 

Re: C to Ada : a piece of code

[Geert Bosch]

Robert Dewar (dewar@cs.nyu.edu) wrote:
`` In most cases, this extra subtraction ends up being essentially free since
   it is always pulled out of loops. In any case, it is perfectly possible
   to have implementations that avoid this subtraction all the time by using
   virtual origins. ''

Please, don't do this! It is possible, but certainly not perfect!  If
applications are long-lived and they dynamically allocate memory at a
certain rate, garbage collection is necessary for keeping the language
safe.

Since Ada-compilers do not provide garbage collection (sad, but still
true), users depend on being able to add a conservative garbage
collector.  Conservative garbage collectors depend on pointers to
objects be stored in a fixed format. Having virtual origins breaks all
conservative garbage collectors and makes it almost impossible for a
third party to add garbage collection to the compiler.

Not being able to write safe applications using dynamically allocated
memory ('global memory objects' might be a better term) is a very
high price to pay for such a tiny performance improvement. 

Of course I'm not biased by the fact that I do have an experimental
garbage collector for GNAT at home ;-)

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943

Re: C to Ada : a piece of code

[Jon S Anthony]

In article <01bb9e40$d0312d80$348371a5@dhoossr.iquest.com> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> <JSA.96Sep8202531@alexandria>...
> > Well, sure.  I guess I should have included an ellipsis after the end
> > loop to show the rest of whatever you might want to do.  Also, there's
> > no reason why you couldn't just eliminate the declare block by means
> > of a subprogram.  As for not using malloc in this case, I see that as
> > a real good thing - no memory management to deal with.  As far as
> > calloc, you can just add an initializer (for unknown reasons since he
> > just sets all the values anyway).  And you can always pass such an
> > array around via parameters or function returns - again no need for
> > the allocator.
>
> Please explain to me how, (since the size of the array required is acquired
> through standard input) if dynamic memory allocation is not used, you're
> going to acquire static memory of the specified size, to which access can
> be safely passed without it's going out of scope.  In fact, gnat has gotten
> smarter than, say, VADS, in this regard, in that it will tell you when
> you're passing access to memory that would be out of scope.

The size of the array stays with it - the type is unconstrained.  If
it is a parameter, then the client has the space allocated for it.  If
it is a function result, the result is (typically) left on the stack
via a "stack shuffel" or by use of parallel stacks (isn't this how
GNAT goes about it now?)  Some early implementations also implicitly
used the heap.  



type My_Array_Type is array ( Natural range <> ) of integer;

procedure P ( X : in out My_Array_Type ) is
begin
    for I in X'Range loop X(i) := i; end loop;
end P;

...
    A : My_Array_Type(1..10);
...
    P(A);

function F ( X : Whatever_Type ) return My_Array_Type is
    A : My_Array_Type(0..Get_Upper_Bound(X)) := (others => 0);
begin
    ...
    return A;
end F;

...
    A : My_Array_Type := F(...);
...
    If A'Length = ... then ...



No user level heap allocations anywhere (and probably no heap allocations
period).  See now?


> > Shrug.  It uglifies the dynamic array allocation (needing a -1).  He
> > said _equivalent_ Ada, not "identical" word for word translation.  In
> > fact, an identical word for word translation of this particular case
> > is just bad Ada.
> 
> The trade off, (in those frequent cases where 0-based indexing is more
> appropriate) is the one-time ugliness of the allocation, vs. the every time
> ugliness of the references which need something like Vect'FIRST subtracted
> during index computation.

First, any such operation (done for constraint check or something
before the loop) is not visible to the user.  Second, no even remotely
decent compiler will do this computation for _any_ of the actual
"indexing" in such a loop as that in question.  Third, I didn't mean
that the 0 based part was the "bad Ada" - the direct user heap
allocation, given the provided context, is what is not "good" Ada
style.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C to Ada : a piece of code

[Jonas Nygren]

Robert Dewar wrote:
> 
> iGeert said, regarding virtual origins
> 
> "Please, don't do this! It is possible, but certainly not perfect!  If
> applications are long-lived and they dynamically allocate memory at a
> certain rate, garbage collection is necessary for keeping the language
> safe.
> 
> Since Ada-compilers do not provide garbage collection (sad, but still
> true), users depend on being able to add a conservative garbage
> collector.  Conservative garbage collectors depend on pointers to
> objects be stored in a fixed format. Having virtual origins breaks all
> conservative garbage collectors and makes it almost impossible for a
> third party to add garbage collection to the compiler."
> 
> Nothing to worry about, obviously the use of virtual origins is only
> possible with fat pointers. So just use thin pointers for your garbage
> collected environment.

What is the Ada syntax for fat pointers versus thin pointers?
(by now many of you know I am an Ada novice, but I have never 
encountered thin/fat pointers in the RM vocabulary, so I just want
to educate myself).

/jonas

Re: C to Ada : a piece of code

[Robert Dewar]

iGeert said, regarding virtual origins

"Please, don't do this! It is possible, but certainly not perfect!  If
applications are long-lived and they dynamically allocate memory at a
certain rate, garbage collection is necessary for keeping the language
safe.

Since Ada-compilers do not provide garbage collection (sad, but still
true), users depend on being able to add a conservative garbage
collector.  Conservative garbage collectors depend on pointers to
objects be stored in a fixed format. Having virtual origins breaks all
conservative garbage collectors and makes it almost impossible for a
third party to add garbage collection to the compiler."

Nothing to worry about, obviously the use of virtual origins is only
possible with fat pointers. So just use thin pointers for your garbage
collected environment.

Re: C to Ada : a piece of code

[Robert Dewar]

Geert says

"Since Ada-compilers do not provide garbage collection (sad, but still
true), users depend on being able to add a conservative garbage
collector."

Note that this statement is a bit broad, it should say "some users might
depend in the future on being able add" .... I don't know of anyone
doing this with GNAT today.

Re: C to Ada : a piece of code

[Geert Bosch]

Robert Dewar said, regarding virtual origins and conservative GC:

`` Nothing to worry about, obviously the use of virtual origins is only
   possible with fat pointers. So just use thin pointers for your
   garbage collected environment. ''

I'm integrating the garbage collector by replacing the malloc function,
so ultimately all heap memory is allocated through my own allocator
that cooperates with the GC.  By doing this the GC is able to quickly
find out the following, given some pointer-like value:

  * Whether it points to or inside (!) a heap object or not
  * If it is a valid pointer:
     * What is the size of the heap object
     * What is the first address occupied by the heap object
     * What are the attributes of the heap object

This information is necessary to write an efficient garbage collector.
If the user stores an access-value to a garbage collected object in 
non-garbage collected memory, the GC has to find that value or it
might remove an object that is still accessible, leading to erroneous
behavior.

The only other alternative would be to keep all garbage collected
objects that happen to have a pointer-like value somewhere in non
garbage-collected memory. However any GC implementation using that
approach will not be of any use because it will trace pointers that
are not reachable anymore. A bad GC is worse than no GC, IMHO.

All conservative garbage collectors I know use a cooperating allocator
that makes it possible to find out the information listed above.

As I found out during my research, it is perfectly possible to add a
very efficient garbage collector to GNAT with only some very small
changes to the run-time library. Hopefully this situation won't be
changed by a small optimization like using virtual origins.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943

Re: C to Ada : a piece of code

[Geert Bosch]

Robert Dewar (dewar@cs.nyu.edu) wrote about adding GC to GNAT:
`` Note that this statement is a bit broad, it should say "some users might
   depend in the future on being able add" .... I don't know of anyone
   doing this with GNAT today. ''

Fortunately I also don't know any GNAT compiler using virtual origins
today. ;-) There are good reasons to want automatic storage deallocation
with Ada-95, while I don't think there are good reasons to want an
Ada implementation to use virtual origins.

Dynamically allocated heap objects are typically used in
situations where the objects are global. This makes deciding when an
object should be deallocated error-prone. Any error a programmer
makes using Unchecked_Deallocation is likely to lead to erroneous
execution or memory leakage. 

The effects of these errors are hard to detect and when detected,
these errors are hard to debug and solve. Since modern garbage
collectors provide a good solution for these problems, it is
very desirable (sp?) to have one for GNAT.

Regards,
   Geert

PS. I refer to "modern GC" as opposed to the old and slow GC
    present in EMACS, for example.
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943

Re: C to Ada : a piece of code

[Robert Dewar]

Geert says

"The effects of these errors are hard to detect and when detected,
these errors are hard to debug and solve. Since modern garbage
collectors provide a good solution for these problems, it is
very desirable (sp?) to have one for GNAT.
"


Yes, but I wold not call the kind of half baked conservative GC you
are talking about a "modern garbage collector", but more like a kludge.
I agree GC is useful, but it needs to be done properly, so that ithas predictable characteristics.
and properly reclaims all unused storage.

Sure, I understand that you can add something half-baked in a 
semi-transparent manner, but (a) as you worry about, it will not
necessarily work in a functionally correct manner, depending on
what code is genrerated, and (b) it may not free storage that
is no longer in use.

Neither behavior seems desirable for any garbage collector, modern or not!

Re: C to Ada : a piece of code

[Robert Dewar]

"As I found out during my research, it is perfectly possible to add a
very efficient garbage collector to GNAT with only some very small
changes to the run-time library. Hopefully this situation won't be
changed by a small optimization like using virtual origins."


Geert, virtual origins are a BIG win for many programs, what makes you
say it is a small optimization ...