From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,18aea7ce90e03321 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-12 05:10:03 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!195.25.12.36!oleane.net!oleane!nnrp.oleane.net!not-for-mail From: "nicolas" Newsgroups: comp.lang.ada Subject: Re: Direct_IO problem -- generic package problem Date: Thu, 12 Jul 2001 14:14:27 +0200 Organization: Guest of France Telecom Oleane's newsreading service Message-ID: <9ik40e$gjd$1@s1.read.news.oleane.net> References: <9ijobe$qb4$1@mercur.foa.se> <9ijpom$bed$1@s1.read.news.oleane.net> NNTP-Posting-Host: 195.101.131.241 X-Trace: s1.read.news.oleane.net 994939731 17005 195.101.131.241 (12 Jul 2001 12:08:51 GMT) X-Complaints-To: abuse@oleane.net NNTP-Posting-Date: Thu, 12 Jul 2001 12:08:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Xref: archiver1.google.com comp.lang.ada:9866 Date: 2001-07-12T14:14:27+02:00 List-Id: 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." 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" > Newsgroups: comp.lang.ada > To: > 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" 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 > > >