* 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 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 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 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: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 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 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