comp.lang.ada
 help / color / mirror / Atom feed
* Direct_IO problem -- generic package problem
@ 2001-07-12  8:42 Magnus Sparf
  2001-07-12  9:19 ` nicolas
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Magnus Sparf @ 2001-07-12  8:42 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

I�m new to ADA (hopefully picking up track fast) and this summer I have the
task of converting an old Ada83 application (VAX environment) to Ada95 (PC
environment).
In the very heart of this application there is a homemade database that
compiles without problem in the VAX environment. When I compile it on GNAT
3.13p in the PC environment. I get the following error:

 db.adb:58:49: actual for "Element_Type" must be a definite subtype :::(the
last line in the extract)

Extract of code (DB is a generic package and used to create a lot of
different databases):
----------------------------------------------------------------------------
-----------
package body DB is

      type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
   pragma pack (FILLED_TABLES);

      type LINE_COL is
         record
            X_V : SMALL_NAT := 1;
            Y_V : SMALL_NAT := 1;
         end record;

      type TABLE_VALUES  is array (SMALL_NAT range <>) of LINE_COL;

      type M_T             is array (SMALL_NAT range <>,
      SMALL_NAT range <>) of ITEM;
      type B_T             is array (SMALL_NAT range <>,
      SMALL_NAT range <>) of BOOLEAN;


      type MATRIX (MAX : SMALL_NAT;
      FIRST_RECORD : BOOLEAN;
      ROWS_FIRST     : SMALL_NAT;
      ROWS_LAST      : SMALL_NAT;
      COLUMNS_FIRST  : SMALL_NAT;
      COLUMNS_LAST   : SMALL_NAT) is

         record
            case FIRST_RECORD is
               when TRUE =>
               -- description of entire file with tables
                  FILLED              : FILLED_TABLES(2..MAX) :=
                  (others => FALSE);
                  DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
                  (others => (1, 1));
               when FALSE =>
               -- tables
                  VALUE        : M_T (ROWS_FIRST..ROWS_LAST,
                  COLUMNS_FIRST..COLUMNS_LAST);
                  ITEM_PUT  : B_T (ROWS_FIRST..ROWS_LAST,
                  COLUMNS_FIRST..COLUMNS_LAST);
                  RAD_INDEX    : R_T (ROWS_FIRST..ROWS_LAST);
                  COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
            end case;
         end record;

      package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
----------------------------------------------------------------------------
-------------

If I give type MATRIX default values it compiles with warnings about Storage
constraints errors in runtime (that also occurs...). MATRIX is used at a lot
of other places further down.

Are there any quick (not dirty) solutions to this problem? My own ideas is
to create separate databases for all eight databases that uses DB (CAR_DB,
BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems like
a lot of work and not very objectoriented.
I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
subtypes in generics" but don`t seem to understand, especially when there�s
a standard package involved.

All you experienced ones out there leave the "Ada is dead"-discussions and
pleaseeeeee help me out...

Magnus Sparf
magnus-s@dsv.su.se






^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12  8:42 Direct_IO problem -- generic package problem Magnus Sparf
@ 2001-07-12  9:19 ` nicolas
  2001-07-12 11:38   ` David C. Hoos, Sr.
  2001-07-12 11:41   ` Magnus Sparf
  2001-07-12 11:33 ` David C. Hoos, Sr.
  2001-07-12 16:58 ` Jeffrey Carter
  2 siblings, 2 replies; 10+ messages in thread
From: nicolas @ 2001-07-12  9:19 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]

If you are using gnat, you can add
pragma Ada_83;
in this body to enforce Ada_83 restrictions (provided you don't use specific
Ada95 features in this body)
But this is really a bug of Ada83 cerrected in Ada95
Nicolas

"Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
9ijobe$qb4$1@mercur.foa.se...
> I�m new to ADA (hopefully picking up track fast) and this summer I have
the
> task of converting an old Ada83 application (VAX environment) to Ada95 (PC
> environment).
> In the very heart of this application there is a homemade database that
> compiles without problem in the VAX environment. When I compile it on GNAT
> 3.13p in the PC environment. I get the following error:
>
>  db.adb:58:49: actual for "Element_Type" must be a definite subtype
:::(the
> last line in the extract)
>
> Extract of code (DB is a generic package and used to create a lot of
> different databases):
> --------------------------------------------------------------------------
--
> -----------
> package body DB is
>
>       type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
>    pragma pack (FILLED_TABLES);
>
>       type LINE_COL is
>          record
>             X_V : SMALL_NAT := 1;
>             Y_V : SMALL_NAT := 1;
>          end record;
>
>       type TABLE_VALUES  is array (SMALL_NAT range <>) of LINE_COL;
>
>       type M_T             is array (SMALL_NAT range <>,
>       SMALL_NAT range <>) of ITEM;
>       type B_T             is array (SMALL_NAT range <>,
>       SMALL_NAT range <>) of BOOLEAN;
>
>
>       type MATRIX (MAX : SMALL_NAT;
>       FIRST_RECORD : BOOLEAN;
>       ROWS_FIRST     : SMALL_NAT;
>       ROWS_LAST      : SMALL_NAT;
>       COLUMNS_FIRST  : SMALL_NAT;
>       COLUMNS_LAST   : SMALL_NAT) is
>
>          record
>             case FIRST_RECORD is
>                when TRUE =>
>                -- description of entire file with tables
>                   FILLED              : FILLED_TABLES(2..MAX) :=
>                   (others => FALSE);
>                   DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
>                   (others => (1, 1));
>                when FALSE =>
>                -- tables
>                   VALUE        : M_T (ROWS_FIRST..ROWS_LAST,
>                   COLUMNS_FIRST..COLUMNS_LAST);
>                   ITEM_PUT  : B_T (ROWS_FIRST..ROWS_LAST,
>                   COLUMNS_FIRST..COLUMNS_LAST);
>                   RAD_INDEX    : R_T (ROWS_FIRST..ROWS_LAST);
>                   COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
>             end case;
>          end record;
>
>       package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> --------------------------------------------------------------------------
--
> -------------
>
> If I give type MATRIX default values it compiles with warnings about
Storage
> constraints errors in runtime (that also occurs...). MATRIX is used at a
lot
> of other places further down.
>
> Are there any quick (not dirty) solutions to this problem? My own ideas is
> to create separate databases for all eight databases that uses DB (CAR_DB,
> BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
like
> a lot of work and not very objectoriented.
> I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> subtypes in generics" but don`t seem to understand, especially when
there�s
> a standard package involved.
>
> All you experienced ones out there leave the "Ada is dead"-discussions and
> pleaseeeeee help me out...
>
> Magnus Sparf
> magnus-s@dsv.su.se
>
>
>





^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12  8:42 Direct_IO problem -- generic package problem Magnus Sparf
  2001-07-12  9:19 ` nicolas
@ 2001-07-12 11:33 ` David C. Hoos, Sr.
  2001-07-12 16:58 ` Jeffrey Carter
  2 siblings, 0 replies; 10+ messages in thread
From: David C. Hoos, Sr. @ 2001-07-12 11:33 UTC (permalink / raw)
  To: comp.lang.ada; +Cc: magnus-s

This sounds like the restriction that was put on generic formal type
declarations with no discriminant part that they be instantiated
only with definite subtypes

If the generic is to be instantiated with indefinite subtypes, then the
formal type declaration of the generic must include the unknown
discriminant part (<>).

For example, if the declaration of Element_Type is

    type Element_Type is private;

then changing the declaration to

    type Element_Type (<>) is private;

will allow (but not require) instantiation to be with indefinite
types.

This is discussed in section 31. of the document found at
http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt

This document deals with the other Ada83/Ada95 compatibility
issues, as well.

----- Original Message -----
From: "Magnus Sparf" <magnus-s@dsv.su.se>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: July 12, 2001 3:42 AM
Subject: Direct_IO problem -- generic package problem


> I�m new to ADA (hopefully picking up track fast) and this summer I have the
> task of converting an old Ada83 application (VAX environment) to Ada95 (PC
> environment).
> In the very heart of this application there is a homemade database that
> compiles without problem in the VAX environment. When I compile it on GNAT
> 3.13p in the PC environment. I get the following error:
>
>  db.adb:58:49: actual for "Element_Type" must be a definite subtype :::(the
> last line in the extract)
>
> Extract of code (DB is a generic package and used to create a lot of
> different databases):
> ----------------------------------------------------------------------------
> -----------
> package body DB is
>
>       type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
>    pragma pack (FILLED_TABLES);
>
>       type LINE_COL is
>          record
>             X_V : SMALL_NAT := 1;
>             Y_V : SMALL_NAT := 1;
>          end record;
>
>       type TABLE_VALUES  is array (SMALL_NAT range <>) of LINE_COL;
>
>       type M_T             is array (SMALL_NAT range <>,
>       SMALL_NAT range <>) of ITEM;
>       type B_T             is array (SMALL_NAT range <>,
>       SMALL_NAT range <>) of BOOLEAN;
>
>
>       type MATRIX (MAX : SMALL_NAT;
>       FIRST_RECORD : BOOLEAN;
>       ROWS_FIRST     : SMALL_NAT;
>       ROWS_LAST      : SMALL_NAT;
>       COLUMNS_FIRST  : SMALL_NAT;
>       COLUMNS_LAST   : SMALL_NAT) is
>
>          record
>             case FIRST_RECORD is
>                when TRUE =>
>                -- description of entire file with tables
>                   FILLED              : FILLED_TABLES(2..MAX) :=
>                   (others => FALSE);
>                   DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
>                   (others => (1, 1));
>                when FALSE =>
>                -- tables
>                   VALUE        : M_T (ROWS_FIRST..ROWS_LAST,
>                   COLUMNS_FIRST..COLUMNS_LAST);
>                   ITEM_PUT  : B_T (ROWS_FIRST..ROWS_LAST,
>                   COLUMNS_FIRST..COLUMNS_LAST);
>                   RAD_INDEX    : R_T (ROWS_FIRST..ROWS_LAST);
>                   COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
>             end case;
>          end record;
>
>       package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> ----------------------------------------------------------------------------
> -------------
>
> If I give type MATRIX default values it compiles with warnings about Storage
> constraints errors in runtime (that also occurs...). MATRIX is used at a lot
> of other places further down.
>
> Are there any quick (not dirty) solutions to this problem? My own ideas is
> to create separate databases for all eight databases that uses DB (CAR_DB,
> BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems like
> a lot of work and not very objectoriented.
> I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> subtypes in generics" but don`t seem to understand, especially when there�s
> a standard package involved.
>
> All you experienced ones out there leave the "Ada is dead"-discussions and
> pleaseeeeee help me out...
>
> Magnus Sparf
> magnus-s@dsv.su.se
>
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12  9:19 ` nicolas
@ 2001-07-12 11:38   ` David C. Hoos, Sr.
  2001-07-12 12:14     ` nicolas
  2001-07-12 11:41   ` Magnus Sparf
  1 sibling, 1 reply; 10+ messages in thread
From: David C. Hoos, Sr. @ 2001-07-12 11:38 UTC (permalink / raw)
  To: comp.lang.ada; +Cc: n.brunot

I don't believe the gnat pragma will help in this situation, because
the restriction is on Ada95 that was not in Ada83.  The real
solution is to fix the code which is very simple to do, viz.:

This sounds like the restriction that was put on generic formal type
declarations with no discriminant part that they be instantiated
only with definite subtypes

If the generic is to be instantiated with indefinite subtypes, then the
formal type declaration of the generic must include the unknown
discriminant part (<>).

For example, if the declaration of Element_Type is

    type Element_Type is private;

then changing the declaration to

    type Element_Type (<>) is private;

will allow (but not require) instantiation to be with indefinite
types.

This is discussed in section 31. of the document found at
http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt

This document deals with the other Ada83/Ada95 compatibility
issues, as well.

----- Original Message -----
From: "nicolas" <n.brunot@cadwin.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: July 12, 2001 4:19 AM
Subject: Re: Direct_IO problem -- generic package problem


> If you are using gnat, you can add
> pragma Ada_83;
> in this body to enforce Ada_83 restrictions (provided you don't use specific
> Ada95 features in this body)
> But this is really a bug of Ada83 cerrected in Ada95
> Nicolas
>
> "Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
> 9ijobe$qb4$1@mercur.foa.se...
> > I�m new to ADA (hopefully picking up track fast) and this summer I have
> the
> > task of converting an old Ada83 application (VAX environment) to Ada95 (PC
> > environment).
> > In the very heart of this application there is a homemade database that
> > compiles without problem in the VAX environment. When I compile it on GNAT
> > 3.13p in the PC environment. I get the following error:
> >
> >  db.adb:58:49: actual for "Element_Type" must be a definite subtype
> :::(the
> > last line in the extract)
> >
> > Extract of code (DB is a generic package and used to create a lot of
> > different databases):
> > --------------------------------------------------------------------------
> --
> > -----------
> > package body DB is
> >
> >       type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> >    pragma pack (FILLED_TABLES);
> >
> >       type LINE_COL is
> >          record
> >             X_V : SMALL_NAT := 1;
> >             Y_V : SMALL_NAT := 1;
> >          end record;
> >
> >       type TABLE_VALUES  is array (SMALL_NAT range <>) of LINE_COL;
> >
> >       type M_T             is array (SMALL_NAT range <>,
> >       SMALL_NAT range <>) of ITEM;
> >       type B_T             is array (SMALL_NAT range <>,
> >       SMALL_NAT range <>) of BOOLEAN;
> >
> >
> >       type MATRIX (MAX : SMALL_NAT;
> >       FIRST_RECORD : BOOLEAN;
> >       ROWS_FIRST     : SMALL_NAT;
> >       ROWS_LAST      : SMALL_NAT;
> >       COLUMNS_FIRST  : SMALL_NAT;
> >       COLUMNS_LAST   : SMALL_NAT) is
> >
> >          record
> >             case FIRST_RECORD is
> >                when TRUE =>
> >                -- description of entire file with tables
> >                   FILLED              : FILLED_TABLES(2..MAX) :=
> >                   (others => FALSE);
> >                   DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> >                   (others => (1, 1));
> >                when FALSE =>
> >                -- tables
> >                   VALUE        : M_T (ROWS_FIRST..ROWS_LAST,
> >                   COLUMNS_FIRST..COLUMNS_LAST);
> >                   ITEM_PUT  : B_T (ROWS_FIRST..ROWS_LAST,
> >                   COLUMNS_FIRST..COLUMNS_LAST);
> >                   RAD_INDEX    : R_T (ROWS_FIRST..ROWS_LAST);
> >                   COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> >             end case;
> >          end record;
> >
> >       package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> > --------------------------------------------------------------------------
> --
> > -------------
> >
> > If I give type MATRIX default values it compiles with warnings about
> Storage
> > constraints errors in runtime (that also occurs...). MATRIX is used at a
> lot
> > of other places further down.
> >
> > Are there any quick (not dirty) solutions to this problem? My own ideas is
> > to create separate databases for all eight databases that uses DB (CAR_DB,
> > BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
> like
> > a lot of work and not very objectoriented.
> > I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> > subtypes in generics" but don`t seem to understand, especially when
> there�s
> > a standard package involved.
> >
> > All you experienced ones out there leave the "Ada is dead"-discussions and
> > pleaseeeeee help me out...
> >
> > Magnus Sparf
> > magnus-s@dsv.su.se
> >
> >
> >
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12  9:19 ` nicolas
  2001-07-12 11:38   ` David C. Hoos, Sr.
@ 2001-07-12 11:41   ` Magnus Sparf
  2001-07-12 12:25     ` nicolas
  1 sibling, 1 reply; 10+ messages in thread
From: Magnus Sparf @ 2001-07-12 11:41 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]

Thanks for the quick reply
I just tried  "pragma Ada_83;" but the only result is a new error message
from GNAT related to the same problem?:
db.adb:58:07: instantiation error at a-direio.adb:190
db.adb:58:07: unconstrained subtype not allowed (need initialization)
db.adb:58:07: instantiation error at a-direio.adb:210
db.adb:58:07: unconstrained subtype not allowed (need initialization)

Is there a way to get around the problem without the use of "pragma Ada_83;"
to this point I have managed to use pure Ada95 standard packages to replace
the old ones specific for the VAX environment. It would be very nice without
compilerdependent solutions.

/Magnus

"nicolas" <n.brunot@cadwin.com> skrev i meddelandet
news:9ijpom$bed$1@s1.read.news.oleane.net...
> If you are using gnat, you can add
> pragma Ada_83;
> in this body to enforce Ada_83 restrictions (provided you don't use
specific
> Ada95 features in this body)
> But this is really a bug of Ada83 cerrected in Ada95
> Nicolas
>
> "Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
> 9ijobe$qb4$1@mercur.foa.se...
> > I�m new to ADA (hopefully picking up track fast) and this summer I have
> the
> > task of converting an old Ada83 application (VAX environment) to Ada95
(PC
> > environment).
> > In the very heart of this application there is a homemade database that
> > compiles without problem in the VAX environment. When I compile it on
GNAT
> > 3.13p in the PC environment. I get the following error:
> >
> >  db.adb:58:49: actual for "Element_Type" must be a definite subtype
> :::(the
> > last line in the extract)
> >
> > Extract of code (DB is a generic package and used to create a lot of
> > different databases):
>
> --------------------------------------------------------------------------
> --
> > -----------
> > package body DB is
> >
> >       type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> >    pragma pack (FILLED_TABLES);
> >
> >       type LINE_COL is
> >          record
> >             X_V : SMALL_NAT := 1;
> >             Y_V : SMALL_NAT := 1;
> >          end record;
> >
> >       type TABLE_VALUES  is array (SMALL_NAT range <>) of LINE_COL;
> >
> >       type M_T             is array (SMALL_NAT range <>,
> >       SMALL_NAT range <>) of ITEM;
> >       type B_T             is array (SMALL_NAT range <>,
> >       SMALL_NAT range <>) of BOOLEAN;
> >
> >
> >       type MATRIX (MAX : SMALL_NAT;
> >       FIRST_RECORD : BOOLEAN;
> >       ROWS_FIRST     : SMALL_NAT;
> >       ROWS_LAST      : SMALL_NAT;
> >       COLUMNS_FIRST  : SMALL_NAT;
> >       COLUMNS_LAST   : SMALL_NAT) is
> >
> >          record
> >             case FIRST_RECORD is
> >                when TRUE =>
> >                -- description of entire file with tables
> >                   FILLED              : FILLED_TABLES(2..MAX) :=
> >                   (others => FALSE);
> >                   DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> >                   (others => (1, 1));
> >                when FALSE =>
> >                -- tables
> >                   VALUE        : M_T (ROWS_FIRST..ROWS_LAST,
> >                   COLUMNS_FIRST..COLUMNS_LAST);
> >                   ITEM_PUT  : B_T (ROWS_FIRST..ROWS_LAST,
> >                   COLUMNS_FIRST..COLUMNS_LAST);
> >                   RAD_INDEX    : R_T (ROWS_FIRST..ROWS_LAST);
> >                   COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> >             end case;
> >          end record;
> >
> >       package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
>
> --------------------------------------------------------------------------
> --
> > -------------
> >
> > If I give type MATRIX default values it compiles with warnings about
> Storage
> > constraints errors in runtime (that also occurs...). MATRIX is used at a
> lot
> > of other places further down.
> >
> > Are there any quick (not dirty) solutions to this problem? My own ideas
is
> > to create separate databases for all eight databases that uses DB
(CAR_DB,
> > BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
> like
> > a lot of work and not very objectoriented.
> > I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> > subtypes in generics" but don`t seem to understand, especially when
> there�s
> > a standard package involved.
> >
> > All you experienced ones out there leave the "Ada is dead"-discussions
and
> > pleaseeeeee help me out...
> >
> > Magnus Sparf
> > magnus-s@dsv.su.se
> >
> >
> >
>
>





^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12 11:38   ` David C. Hoos, Sr.
@ 2001-07-12 12:14     ` nicolas
  0 siblings, 0 replies; 10+ messages in thread
From: nicolas @ 2001-07-12 12:14 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6188 bytes --]

But that means that you cannot use the predefined generic package Direct_IO
any more ...
With the given code, the pragma Ada_83 is the simplest solution I see which
doesn't require code rewriting..
In most similar cases I met, if everything worked well in Ada83, this pragma
allows you to compile and run in Ada95.
If this works, and if there is a strong deadline for a usable version of the
software, delaying the rewriting of the implementation is not necesseraly a
bad option.

Of course, it would be much better to rewrite the implementation without
Direct_IO, or with another IO implementation, if you can afford it.
Direct_IO can be compiler specific (unfortunately pragma Ada_83 is compiler
specific too ...)

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> a �crit dans le message
news: mailman.994937958.12891.comp.lang.ada@ada.eu.org...
> I don't believe the gnat pragma will help in this situation, because
> the restriction is on Ada95 that was not in Ada83.  The real
> solution is to fix the code which is very simple to do, viz.:
>
> This sounds like the restriction that was put on generic formal type
> declarations with no discriminant part that they be instantiated
> only with definite subtypes
>
> If the generic is to be instantiated with indefinite subtypes, then the
> formal type declaration of the generic must include the unknown
> discriminant part (<>).
>
> For example, if the declaration of Element_Type is
>
>     type Element_Type is private;
>
> then changing the declaration to
>
>     type Element_Type (<>) is private;
>
> will allow (but not require) instantiation to be with indefinite
> types.
>
> This is discussed in section 31. of the document found at
> http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt
>
> This document deals with the other Ada83/Ada95 compatibility
> issues, as well.
>
> ----- Original Message -----
> From: "nicolas" <n.brunot@cadwin.com>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: July 12, 2001 4:19 AM
> Subject: Re: Direct_IO problem -- generic package problem
>
>
> > If you are using gnat, you can add
> > pragma Ada_83;
> > in this body to enforce Ada_83 restrictions (provided you don't use
specific
> > Ada95 features in this body)
> > But this is really a bug of Ada83 cerrected in Ada95
> > Nicolas
> >
> > "Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
> > 9ijobe$qb4$1@mercur.foa.se...
> > > I�m new to ADA (hopefully picking up track fast) and this summer I
have
> > the
> > > task of converting an old Ada83 application (VAX environment) to Ada95
(PC
> > > environment).
> > > In the very heart of this application there is a homemade database
that
> > > compiles without problem in the VAX environment. When I compile it on
GNAT
> > > 3.13p in the PC environment. I get the following error:
> > >
> > >  db.adb:58:49: actual for "Element_Type" must be a definite subtype
> > :::(the
> > > last line in the extract)
> > >
> > > Extract of code (DB is a generic package and used to create a lot of
> > > different databases):
> >
> --------------------------------------------------------------------------
> > --
> > > -----------
> > > package body DB is
> > >
> > >       type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> > >    pragma pack (FILLED_TABLES);
> > >
> > >       type LINE_COL is
> > >          record
> > >             X_V : SMALL_NAT := 1;
> > >             Y_V : SMALL_NAT := 1;
> > >          end record;
> > >
> > >       type TABLE_VALUES  is array (SMALL_NAT range <>) of LINE_COL;
> > >
> > >       type M_T             is array (SMALL_NAT range <>,
> > >       SMALL_NAT range <>) of ITEM;
> > >       type B_T             is array (SMALL_NAT range <>,
> > >       SMALL_NAT range <>) of BOOLEAN;
> > >
> > >
> > >       type MATRIX (MAX : SMALL_NAT;
> > >       FIRST_RECORD : BOOLEAN;
> > >       ROWS_FIRST     : SMALL_NAT;
> > >       ROWS_LAST      : SMALL_NAT;
> > >       COLUMNS_FIRST  : SMALL_NAT;
> > >       COLUMNS_LAST   : SMALL_NAT) is
> > >
> > >          record
> > >             case FIRST_RECORD is
> > >                when TRUE =>
> > >                -- description of entire file with tables
> > >                   FILLED              : FILLED_TABLES(2..MAX) :=
> > >                   (others => FALSE);
> > >                   DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> > >                   (others => (1, 1));
> > >                when FALSE =>
> > >                -- tables
> > >                   VALUE        : M_T (ROWS_FIRST..ROWS_LAST,
> > >                   COLUMNS_FIRST..COLUMNS_LAST);
> > >                   ITEM_PUT  : B_T (ROWS_FIRST..ROWS_LAST,
> > >                   COLUMNS_FIRST..COLUMNS_LAST);
> > >                   RAD_INDEX    : R_T (ROWS_FIRST..ROWS_LAST);
> > >                   COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> > >             end case;
> > >          end record;
> > >
> > >       package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> >
> --------------------------------------------------------------------------
> > --
> > > -------------
> > >
> > > If I give type MATRIX default values it compiles with warnings about
> > Storage
> > > constraints errors in runtime (that also occurs...). MATRIX is used at
a
> > lot
> > > of other places further down.
> > >
> > > Are there any quick (not dirty) solutions to this problem? My own
ideas is
> > > to create separate databases for all eight databases that uses DB
(CAR_DB,
> > > BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
> > like
> > > a lot of work and not very objectoriented.
> > > I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> > > subtypes in generics" but don`t seem to understand, especially when
> > there�s
> > > a standard package involved.
> > >
> > > All you experienced ones out there leave the "Ada is dead"-discussions
and
> > > pleaseeeeee help me out...
> > >
> > > Magnus Sparf
> > > magnus-s@dsv.su.se
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >
>





^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12 11:41   ` Magnus Sparf
@ 2001-07-12 12:25     ` nicolas
  0 siblings, 0 replies; 10+ messages in thread
From: nicolas @ 2001-07-12 12:25 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

It seems that Gnat implementation of Direct_IO is not compatible with the
use of pragma Ada_83 (Is this a bug ?)
You should list what you use from Direct_IO, and write your own My_Direct_IO
package (not necessarely generic)
Anyway if you use this package for save/load, you need a file format which
is not Gnat specific.

"Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
9ik2qt$1p2$1@mercur.foa.se...
> Thanks for the quick reply
> I just tried  "pragma Ada_83;" but the only result is a new error message
> from GNAT related to the same problem?:
> db.adb:58:07: instantiation error at a-direio.adb:190
> db.adb:58:07: unconstrained subtype not allowed (need initialization)
> db.adb:58:07: instantiation error at a-direio.adb:210
> db.adb:58:07: unconstrained subtype not allowed (need initialization)
>
> Is there a way to get around the problem without the use of "pragma
Ada_83;"
> to this point I have managed to use pure Ada95 standard packages to
replace
> the old ones specific for the VAX environment. It would be very nice
without
> compilerdependent solutions.
>
> /Magnus






^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12  8:42 Direct_IO problem -- generic package problem Magnus Sparf
  2001-07-12  9:19 ` nicolas
  2001-07-12 11:33 ` David C. Hoos, Sr.
@ 2001-07-12 16:58 ` Jeffrey Carter
  2001-07-12 19:23   ` tmoran
  2 siblings, 1 reply; 10+ messages in thread
From: Jeffrey Carter @ 2001-07-12 16:58 UTC (permalink / raw)


In Ada 83, you could say

generic -- Example
   type T is limited private;
package Example is
   ...
end Example;

and then, before supplying a body for Example, write something like

package P is new Example (T => String);

Then you could supply a body for example that creates a variable of type
T:

package body Example is
   V : T;
   ...
end Example;

This is the same as writing

   V : String;

which is clearly illegal. This would be caught eventually, but was a
"gotcha" that was removed in Ada 95. Now the generic formal type as
given means that it must be possible to declare a variable of the type
(the type must be "definite"). The new generic formal syntax

type T (<>) is [limited] private;

allows the generic to be instantiated with an indefinite type, but means
the generic cannot declare any uninitialized objects of the type.

Ada.Direct_IO declares the generic formal type

type Element_Type is private;

so the type used to instantiate Direct_IO must be definite, while your
type Matrix is indefinite. You have a few possibilities

Use a subtype in place of Small_Nat with a small enough range that you
can provide defaults for all discriminants without encountering
Storage_Error if you declare an unconstrained variable.

Instantiate Direct_IO with constrained subtypes of Matrix for the types
of interest.

Good luck.

-- 
Jeffrey Carter



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12 16:58 ` Jeffrey Carter
@ 2001-07-12 19:23   ` tmoran
  2001-07-13  8:16     ` Magnus Sparf
  0 siblings, 1 reply; 10+ messages in thread
From: tmoran @ 2001-07-12 19:23 UTC (permalink / raw)


>Instantiate Direct_IO with constrained subtypes of Matrix for the types
>of interest.
i.e.
>My own ideas is to create separate databases for all eight databases
>that uses DB (CAR_DB, BOAT_DB, HOUSE_DB...) with specified values for
>MATRIX, but that seems like a lot of work and not very objectoriented.
  If you are doing direct IO all the records in a given file need to
be the same size anyway, so it certainly is reasonable to instantiate
Ada.Direct_IO once for each of the eight database files.  Did the
old program actually mix different size records in a single file?  How
did it know where to look for record N?  As for OO, if you have a
root Matrix tagged type make it abstract, then each of the eight
children should have its own overide of its input/output routines
using the appropriate instantiation.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Direct_IO problem -- generic package problem
  2001-07-12 19:23   ` tmoran
@ 2001-07-13  8:16     ` Magnus Sparf
  0 siblings, 0 replies; 10+ messages in thread
From: Magnus Sparf @ 2001-07-13  8:16 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]


<tmoran@acm.org> skrev i meddelandet
news:4Pm37.178065$%i7.116159417@news1.rdc1.sfba.home.com...
> >Instantiate Direct_IO with constrained subtypes of Matrix for the types
> >of interest.
> i.e.
> >My own ideas is to create separate databases for all eight databases
> >that uses DB (CAR_DB, BOAT_DB, HOUSE_DB...) with specified values for
> >MATRIX, but that seems like a lot of work and not very objectoriented.
>   If you are doing direct IO all the records in a given file need to
> be the same size anyway, so it certainly is reasonable to instantiate
> Ada.Direct_IO once for each of the eight database files.  Did the
> old program actually mix different size records in a single file?  How
> did it know where to look for record N?

No,  the program created a separate file for each database.
The big problem for me with this program is that the part about the
database(s) i totally uncommented and there is no documentation what so
ever. And the person who originally designed is gone since 13 years ago and
probably doesn�t remember anything.

> As for OO, if you have a
> root Matrix tagged type make it abstract, then each of the eight
> children should have its own overide of its input/output routines
> using the appropriate instantiation.

Sounds like a great concept

/Magnus
magnus-s@dsv.su.se






^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2001-07-13  8:16 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-12  8:42 Direct_IO problem -- generic package problem Magnus Sparf
2001-07-12  9:19 ` nicolas
2001-07-12 11:38   ` David C. Hoos, Sr.
2001-07-12 12:14     ` nicolas
2001-07-12 11:41   ` Magnus Sparf
2001-07-12 12:25     ` nicolas
2001-07-12 11:33 ` David C. Hoos, Sr.
2001-07-12 16:58 ` Jeffrey Carter
2001-07-12 19:23   ` tmoran
2001-07-13  8:16     ` Magnus Sparf

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