C++ to Ada95, help please

C++ to Ada95, help please

[Simon Johnston]

Hi, I am moving over to Ada95 from C++, I did do some Ada a while ago, and I
am fairly confident, but I need some help to move some C++ knowledge onto
Ada95.

First I would like to declare an Opaque type, or in C++ a 'smiley'.  There
are two uses for such a feature. First, where a class' implementation may
change greatly, and I want to really hide this from clients I would declare
a class for the implementation and hide it. C++ allows this as if you only
use a pointer to the opaque type then the compiler knows the size of it and
does not need to know more. The second is where you have some information 
that the client may request, but the client can only use it by passing it 
back to you. I have used this in a text screen class to save and restore the
screen contents, the client cannot manipulate the screen object as they 
cannot know what it is, and as the screen object is platform dependant I can
use a completely different implementation behind the scenes. I include two 
examples below to illustrate.

// Start ->
class ACollectionClass {
public:
  ...
private:
  class Implementation;
  Implementation* hidden;
};

class Screen {
public:
  ...
  class SavedScreen;
  const SavedScreen* save(void);
  void  restore(SavedScreen* image);
};
// <- end.

Now I know from experience I can do this sort of thing in C++, Modula-2 and
Modula-3 but I cannot see how to do it in Ada, even using private types.


Thanks very much.

MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer (C/C++)      |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston@bra0801.wins.icl.co.uk       |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476302|United Kingdom     |
|Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.

Re: C++ to Ada95, help please

[Robert A Duff]

In article <3jjnru$e02@jerry.rb.icl.co.uk>,
Simon Johnston <skj@rb.icl.co.uk> wrote:
>First I would like to declare an Opaque type, or in C++ a 'smiley'.  There
>are two uses for such a feature. ...

I'm not sure exactly what you're asking for, but perhaps you want to do
something like this:

    package P is
        type T is private;
    private
        type Rec; -- Incomplete type, completed in body.
        type T is access Rec;
    end P;

    package body P is
        type Rec is
            record
                ...
            end record;
    end P;

- Bob

Re: C++ to Ada95, help please

[Tucker Taft]

Simon Johnston (skj@rb.icl.co.uk) wrote:
: Hi, I am moving over to Ada95 from C++, I did do some Ada a while ago, and I
: am fairly confident, but I need some help to move some C++ knowledge onto
: Ada95.

: First I would like to declare an Opaque type, or in C++ a 'smiley'.  There
: are two uses for such a feature. 
: ...I include two 
: examples below to illustrate.

: // Start ->
: class ACollectionClass {
: public:
:   ...
: private:
:   class Implementation;
:   Implementation* hidden;
: };

Ada has a very direct equivalent to this:

    package A is
        type Collection is tagged private;
      ...
    private
	type Implementation;    -- This is called an "incomplete type"
			        -- it can only be used as the designated
				-- type for an access type before
				-- it is fully defined.
				-- The full definition may be deferred to the
				-- package body if the incomplete type
				-- definition is in the private part of
				-- the package spec.
        type Impl_Ptr is access Implementation;

        type Collection is tagged record
           B : Impl_Ptr;
        end record;
    end A;

  -- in the body for package A we would give the full definition
  -- of Implementation.

: class Screen {
: public:
:   ...
:   class SavedScreen;
:   const SavedScreen* save(void);
:   void  restore(SavedScreen* image);
: };
: // <- end.

This one is similar to the above, except that you export the access
type as a private type:

    package Screens is
        type SavedScreen is private;
	type Screen is tagged private;
        function Save(S : Screen) return Saved_Screen;
	procedure Restore(S : in out Screen; From : Saved_Screen);
    private
        type SavedScreen_Impl;
        type SavedScreen is access SavedScreen_Impl;

        type Screen is tagged record
           ...
        end record;
    end Screens;

  -- In the body for Screens, we would give the full definition
  -- for SavedScreen_Impl.

: Now I know from experience I can do this sort of thing in C++, Modula-2 and
: Modula-3 but I cannot see how to do it in Ada, even using private types.

As illustrated above, the thing you need to use are access types,
and a designated type which is an incomplete type whose full
type definition is deferred to the package body
(so called "deferred incomplete types")  This feature is
available in both Ada 83 and Ada 95.  

In Ada 95, you have the additional possibility of using abstract 
types and access-to-class-wide, which would allow the completion
of the "impl" types potentially in other packages, but
at least in the above cases, that seems like overkill.

If you are familiar with Modula-2, then an 
"access-to-deferred-incomplete-type" is almost identical
in functionality to Modula-2's "opaque" types.

: |Simon K. Johnston - Development Engineer (C/C++)      |ICL Retail Systems |
: |------------------------------------------------------|3/4 Willoughby Road|
: |Unix Mail : S.K.Johnston@bra0801.wins.icl.co.uk       |Bracknell, Berks   |
: |Telephone : +44 (0)344 476320   Fax: +44 (0)344 476302|United Kingdom     |
: |Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: C++ to Ada95, help please

[Simon Johnston]

Hi, thanks everyone for helping with my last query. I have a new C nasty for
you. I am converting some C headers into packages for use with GNAT and 
have come accross the old chestnut:

typedef struct _STRUCT_NAME {.....type struct_STRUCT_NAME is
....................................record
  int item1;..........................item1  : int;
  union {                             :
    int  u_item1;                     :
    long u_item2;                     :
  } u_name;                           :
  int item2;..........................item2  : int;
....................................end record;
} STRUCT_NAME;....................type STRUCT_NAME is new struct_STRUCT_NAME;

this I know is a contrived example but it does show the problem, how do I
describe the C struct on the left as an Ada record on the right. (The code
I have put on the right is lifted from the windows.ads package spec provided
in the GNAT examples directory for Windows NT.

Thanks.


MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer (C/C++)      |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston@bra0801.wins.icl.co.uk       |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476302|United Kingdom     |
|Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.

Re: C++ to Ada95, help please

[Kevin F. Quinn]

In article <3kjd2m$d3t@jerry.rb.icl.co.uk>,
          skj@rb.icl.co.uk (Simon Johnston) wrote:

> Hi, thanks everyone for helping with my last query. I have a new C nasty for
> you. I am converting some C headers into packages for use with GNAT and 
> have come accross the old chestnut:
> 
> typedef struct _STRUCT_NAME {.....type struct_STRUCT_NAME is
> ....................................record
>   int item1;..........................item1  : int;
>   union {                             :
>     int  u_item1;                     :
>     long u_item2;                     :
>   } u_name;                           :
>   int item2;..........................item2  : int;
> ....................................end record;
> } STRUCT_NAME;....................type STRUCT_NAME is new struct_STRUCT_NAME

> 
> this I know is a contrived example but it does show the problem, how do I
> describe the C struct on the left as an Ada record on the right. (The code
> I have put on the right is lifted from the windows.ads package spec provided
> in the GNAT examples directory for Windows NT.
> 
> Thanks.

Yeuch!  If "int" and "long" are not the same size, any amount of
tricksy mucking about could happen.  I would be tempted to write:


  type u_name_union_type is
    record
      u_item1 : Unsigned_Integer;            <- or whatever.
      u_item2 : Unsigned_LongInteger;        <-
    end record;

  type struct_STRUCT_NAME is
    record
      item1  : Integer;
      u_name : u_name_union_type;
      item2  : Integer;
    end record;


in the first instance.  The naming structure would then remain, although
the actual data layout would be different.  If the layout is important,
then how about:

  type struct_STRUCT_NAME is
    record
      item1  : Integer;
      u_name : LongInteger;          <-- type is the size of the union.
      item2  : Integer;
    end record;

  function u_item1(u_uname : in LongInteger) return Integer;
  function u_item2(u_uname : in LongInteger) return LongInteger;

where function u_item1 returns the lower half of the u_name parameter
(several ways to do this - best way will depend on the compiler).

Unfortunately, this mucks up the naming structure; you need to use

   item1_value := u_item1(struct.u_name);

instead of

   item1_value := struct.u_name.u_item1;

(which works with the top version).



Of course, unions are usually used in 'C' for variant records, which
you can do in Ada.  'twill depend on how well the compiler allows
you to specify the actual layout of the variant record that decides
whether this would work well enough.  It's unlikely, though, given the
layout above.

You could declare a separate type for each union element, then declare
several data items, and alias them  [fx: throws up :) ]

For example:

  type u_name_item1_type is
    record
      u_item1 : Integer;
      padding : Integer;     <-- Assuming LongInteger'size=2xInteger'size
    end record;                  Anyway, in general some padding will be
                                 required.
  type u_name_item2_type is
    record
      u_item2 : LongInteger;
    end record;

  type struct_STRUCT_NAME is
    record
      item1  : Integer;
      u_name : u_name_item1_type;
      item2  : Integer;
    end record;

  type struct_STRUCT_NAME_item2 is
    record
      item1  : Integer;
      u_name : u_name_item1_type;
      item2  : Integer;
    end record;

  DataItem : struct_STRUCT_NAME;
  DataItem2 : struct_STRUCT_NAME_item2;
  for DataItem2 use at DataItem'Address;

and use DataItem2 whenever you need to access .u_name.u_item2.

Hmm.  Interesting problem.  There's probably a nice simple solution;
I just can't see one :)
-- 
Kevin F. Quinn           * "That's not what you said when you sent him your
kevq@banana.demon.co.uk  * Navel."   "Novel, Baldrick, not navel."
kevq@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525  * to me..."                        BlackAdder III
... Death is proven to be 99.9% fatal to all laboratory rats.

Re: C++ to Ada95, help please

[Tucker Taft]

Simon Johnston (skj@rb.icl.co.uk) wrote:

: Hi, thanks everyone for helping with my last query. I have a new C nasty for
: you. I am converting some C headers into packages for use with GNAT and 
: have come accross the old chestnut:

: typedef struct _STRUCT_NAME {.....type struct_STRUCT_NAME is
: ....................................record
:   int item1;..........................item1  : int;
:   union {                             :
:     int  u_item1;                     :
:     long u_item2;                     :
:   } u_name;                           :
:   int item2;..........................item2  : int;
: ....................................end record;
: } STRUCT_NAME;....................type STRUCT_NAME is new struct_STRUCT_NAME;

: this I know is a contrived example but it does show the problem, how do I
: describe the C struct on the left as an Ada record on the right. (The code
: I have put on the right is lifted from the windows.ads package spec provided
: in the GNAT examples directory for Windows NT.

I believe GNAT supports a pragma "Unchecked_Union" (approximately) which
is applied to a discriminated record to make it look like a C
union.  The basic model is that a C union is essentially an undiscriminated
variant record.  The pragma requests the compiler to omit the
discriminant in memory, though it still exists "conceptually."

To use this pragma, you would first declare your inner union as follows:
     
    type U_Name_Enum is (U_int, U_long);
    type U_Name_Union(Kind : U_Name_Enum := U_int) is record
        case Kind is
            when U_int => U_item1 : Interfaces.C.int;
            when U_long => U_Item2 : Interfaces.C.long;
        end case;
    end record;
    pragma Unchecked_Union(U_Name_Union);

You can then use the "union" as a component of your record:

    type struct_STRUCT_NAME is record
        item1 : Interfaces.C.int;
        u_name : U_Name_Union;
        item2 : Interfaces.C.int;
    end record;
    
You create values of the union type using a normal record aggregate,
such as:

    X : U_Name_Union := (Kind => U_int, U_item1 => 33);

The discriminant is required in the aggregate, even though no discriminant
is actually stored in memory.  I believe that the pragma Unchecked_Union
causes an implicit "pragma Suppress(Discriminant_Check, On => <union>);"
so that no discriminant checks are performed when selecting a component
of a union (caveat programmor).  It is illegal to directly select the
discriminant itself in the presence of this pragma.  

Note that for initial Ada-only unit testing you might want to comment out 
the pragma, so that discriminant checks are performed.  Once you actually 
start interfacing with C, you will have to uncomment the pragma again
to get rid of the space for the discriminant.

It is hoped that this pragma will become a defacto standard for Ada 95
compilers that support interfacing to C.

: |Simon K. Johnston - Development Engineer (C/C++)      |ICL Retail Systems |
: |------------------------------------------------------|3/4 Willoughby Road|
: |Unix Mail : S.K.Johnston@bra0801.wins.icl.co.uk       |Bracknell, Berks   |
: |Telephone : +44 (0)344 476320   Fax: +44 (0)344 476302|United Kingdom     |
: |Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: C++ to Ada95, help please

[Vladimir Vukicevic]

In article <3kjd2m$d3t@jerry.rb.icl.co.uk>,
          skj@rb.icl.co.uk (Simon Johnston) wrote:

I think you want something like:

package Foo is
    type A_Type is (FOO, BAR);
    for A_Type'Size use 8;	--  Should probably be Integer'Size or whatever
    for A_Type use
        (FOO => 1, BAR => 2);

    type Blah (disc : A_Type) is
        record
            case disc is
                when FOO =>
                    one : Integer;
                when BAR =>
                    two : Integer;
            end case;
        end record;

    for Blah use
        record
            disc at 0 range 0 .. (A_Type'Size-1);
            one at 1 range 0 .. (Integer'Size-1);
            two at 1 range 0 .. (Integer'Size-1);
        end record;
end Foo;

With the right types and sizes, of course, but this should work. Note that
you have to speicifically decide which of the variables you want to be
your discriminant; in your example, item1 or item2... if these can only
legally hold values of constants, you should consider creating an
enumerated type with a representation clause, as above.

	- Vladimir

Re: C++ to Ada95, help please

[Robb Nebbe]

In article <D5tIGu.Cn6@inmet.camb.inmet.com>, stt@henning.camb.inmet.com (Tucker Taft) writes:

|> 
|> I believe GNAT supports a pragma "Unchecked_Union" (approximately) which
|> is applied to a discriminated record to make it look like a C
|> union.  The basic model is that a C union is essentially an undiscriminated
|> variant record.  The pragma requests the compiler to omit the
|> discriminant in memory, though it still exists "conceptually."

The solution I have used is to declare each variant as a separate type
and use a rep clause for the size. Then I use Unchecked_Conversion to
change between views.

It seems to me that the Unchecked_Union pragma would be a better solution
if the compiler provides it.

Robb Nebbe

Re: C++ to Ada95, help please

[Mike Meier]

Tucker Taft (stt@henning.camb.inmet.com) wrote:
: I believe GNAT supports a pragma "Unchecked_Union" (approximately) which
: is applied to a discriminated record to make it look like a C
: union.

: <snip>

: It is hoped that this pragma will become a defacto standard for Ada 95
: compilers that support interfacing to C.

: -Tucker Taft  stt@inmet.com
: Intermetrics, Inc.

I hate to pick a bone with Tuck just after approval of Ada 95.  But, if
he hopes this will become a defacto standard, why wasn't it just included
in the language definition?

Mike Meier
Magnavox Electronic Systems Company

Re: C++ to Ada95, help please

[Robert Dewar]

GNAT does not yet support the Unchecked_Union pragma mentioned by Tuck

Re: C++ to Ada95, help please

[Stephen A. Leake]

In article <3kjd2m$d3t@jerry.rb.icl.co.uk> skj@rb.icl.co.uk (Simon
Johnston) writes:

In article <3kjd2m$d3t@jerry.rb.icl.co.uk> skj@rb.icl.co.uk (Simon
Johnston) writes:



   typedef struct _STRUCT_NAME {.....type struct_STRUCT_NAME is
   ....................................record
     int item1;..........................item1  : int;
     union {                             :
       int  u_item1;                     :
       long u_item2;                     :
     } u_name;                           :
     int item2;..........................item2  : int;
   ....................................end record;
   } STRUCT_NAME;....................type STRUCT_NAME is new struct_STRUCT_NAME;

The Ada (near) equivalent of a C union is a variant record, but you
need a discriminant. I'll assume item1 is used as a discriminant in
the C structure (good C code does include discriminants); that is, the
value of item1 tells you whether to use u_item1 or u_item2. Then the Ada
equivalent is:

type DISCRIMINANTS is (One, Two);
for DISCRIMINANTS use (One => ?, Two => ?);
type struct_STRUCT_NAME (item1 : DISCRIMINANTS) is
record
	case item1 is
	when One =>
		u_item1 : int;
	when Two =>
		u_item2 : int;
	end case;
	item2 : int
end record;

If item1 (or item2) is not used in this way, there is no direct Ada
equivalent structure (and the C code is not very good!).

- Stephe
--
Stephen Leake, NASA Goddard Space Flight Center
email: Stephen.Leake@gsfc.nasa.gov

Re: C++ to Ada95, help please

[Tucker Taft]

Mike Meier (mjmeie@ss5.magec.com) wrote:

> Tucker Taft (stt@henning.camb.inmet.com) wrote:
> : I believe GNAT supports a pragma "Unchecked_Union" (approximately) which
> : is applied to a discriminated record to make it look like a C
> : union.

> : <snip>

> : It is hoped that this pragma will become a defacto standard for Ada 95
> : compilers that support interfacing to C.

> : -Tucker Taft  stt@inmet.com
> : Intermetrics, Inc.

> I hate to pick a bone with Tuck just after approval of Ada 95.  But, if
> he hopes this will become a defacto standard, why wasn't it just included
> in the language definition?

There is a fairly big difference between a defacto standard and a dejure 
standard in terms of lead-time, energy required, etc.  If such a pragma had 
been proposed a few years ago, we could have done the work to write it up 
precisely in Reference-Manual-ease, and sent it around for review, and 
revised it, and polished it, and ...  Unfortunately, the consensus developed
around this pragma only in the past 6 months.

In any case, I would expect there to be many de-facto standards
in the area of implementation-defined pragmas, attributes, and
generally useful packages.  The Uniformity Rapporteur Group (URG)
of the ISO Working Group on Ada (WG9) was established specifically
to encourage uniformity in areas that were left open to implementor
and user creativity by the inevitably limited standardization process.

I would expect GNAT to be the vanguard for defacto standards, since
it will be freely available on so many platforms.  Other Ada 95 vendors
will probably try to follow GNAT's lead, unless there is a real
dispute about the appropriateness of a pragma or attribute.
The URG will probably emerge as the forum for resolving such disputes.

> Mike Meier
> Magnavox Electronic Systems Company

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: C++ to Ada95, help please

[Vladimir Vukicevic]

In article <SAL714.95Mar23130133@rs710.gsfc.nasa.gov> sal714@rs710.gsfc.nasa.gov (Stephen A. Leake) writes:

: type DISCRIMINANTS is (One, Two);
: for DISCRIMINANTS use (One => ?, Two => ?);
: type struct_STRUCT_NAME (item1 : DISCRIMINANTS) is
: record
: 	case item1 is
: 	when One =>
: 		u_item1 : int;
: 	when Two =>
: 		u_item2 : int;
: 	end case;
: 	item2 : int
: end record;
: 
: If item1 (or item2) is not used in this way, there is no direct Ada
: equivalent structure (and the C code is not very good!).

Of course, a representation clause for the record is needed above, as
there are no guarantees that the Ada compiler will arrange this record
in memory to correspond to the C struct/union. Something like the following
is needed:

for struct_STRUCT_NAME use
	record
		item1 at 0 range 0 .. 7;
		u_item1 at 1 range 0 .. 7;
		u_item2 at 1 range 0 .. 7;
		item2 at 2 range 0 ..7;
	end record;

Note that, because of 13.5.1 (11), you can't just define a record rep
clause with overlapping components; they must be distinct variants.

	- Vladimir

Re: C++ to Ada95, help please

[Robert Dewar]

Why wasn't pragma Unchecked_Union included in Ada 95?

Really two reasons:

First: it simply wasn't thought of until very recently. Mitch Gart started
a conversation on this issue quite recently, and the suggestion of
pragma Unchecked_Union came out of these discussions. I still wouldn't
regard the design as solid enough to even semi-standardize without more
perusal and experience.

Second: there is a limit on how far it is reasonable to go in the definition
of such language interface details. For one thing, an accurate description of
them depends on the semantics of the other language, so it gets quite tricky.

Third (3 of 2 :-) the Unchecked_Union feature is really rather unpleasant
as a full blown language feature, and putting it in the Ada RM would perhaps
give it TOO much status. There is nothing to stop this being used in Ada
programs quite independently of C (except good taste!)

Re: C++ to Ada95, help please

[Keith Thompson]

In <VLADIMIR.95Mar24010728@speedy.intrepid.com> vladimir@speedy.intrepid.com (Vladimir Vukicevic) writes:
> Of course, a representation clause for the record is needed above, as
> there are no guarantees that the Ada compiler will arrange this record
> in memory to correspond to the C struct/union. Something like the following
> is needed:
> 
> for struct_STRUCT_NAME use
> 	record
> 		item1 at 0 range 0 .. 7;
> 		u_item1 at 1 range 0 .. 7;
> 		u_item2 at 1 range 0 .. 7;
> 		item2 at 2 range 0 ..7;
> 	end record;

In Ada 95, you can just use

    pragma Convention(C, struct_STRUCT_NAME);

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.

Re: C++ to Ada95, help please

[Norman H. Cohen]

In article <3kvdai$kjk@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: 
|> Why wasn't pragma Unchecked_Union included in Ada 95?
|>
|> Really two reasons: 
|>
|> First: ...
|>
|> Second: ...
|>
|> Third (3 of 2 :-) ...

There are three kinds of people in this world:  Those who know how to
count and those who don't.

--
Norman H. Cohen    ncohen@watson.ibm.com