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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5117b1b6391a0e06 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!nwrdny01.gnilink.net.POSTED!0f19ed38!not-for-mail From: "Frank J. Lhota" Newsgroups: comp.lang.ada References: <1087410710.477506@master.nyc.kbcfp.com> Subject: Re: A simple ADA puzzle (I haven't the answer) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: Date: Thu, 24 Jun 2004 15:19:51 GMT NNTP-Posting-Host: 141.154.215.169 X-Complaints-To: abuse@verizon.net X-Trace: nwrdny01.gnilink.net 1088090391 141.154.215.169 (Thu, 24 Jun 2004 11:19:51 EDT) NNTP-Posting-Date: Thu, 24 Jun 2004 11:19:51 EDT Xref: g2news1.google.com comp.lang.ada:1856 Date: 2004-06-24T15:19:51+00:00 List-Id: "Randy Brukardt" wrote in message news:fd2dndsj1oy3aUTdRVn-vA@megapath.net... > "Hyman Rosen" wrote in message > news:1087410710.477506@master.nyc.kbcfp.com... > > Just the fact that > > type LEN_TYPE is array (INTEGER range <>) of CHARACTER; > > type STRING_TYPE (LEN : INTEGER := 0) is > > record STRING : LEN_TYPE (1 .. LEN); end record; > > X : STRING_TYPE; > > can result in the allocation of all of memory is completely > > counterintuitive. > > And just plain wrong, IMHO. The decision to allow Ada 83 compilers to > emasculate this critically useful feature was one of the worst made. (If > that decision had not been made, we wouldn't really need > Ada.Strings.Unbounded, among other things.) The original ACVC tests required > this to work, and people put pressure on the AVO to get them removed. > > But, it's too late to reverse this decision (changing this has far reaching > consequences in compilers, and that makes the cost too high to contemplate). > Sigh. So if I understand the concept correctly, the way a compiler could handle this type declaration would be to always allocate objects of this type off of a heap, so that sizes could be adjusted as needed. In othr words, when you declare My_String : STRING_TYPE; then My_String could actually hold a pointer to an object on the heap, with the current LEN discriminant. If My_String were assigned a value with a different value of LEN, the pointer in My_String would be changed if necessary to point to a heap object of the appropriate size. Is this the Janus Ada approach? AFAICT this approach would not conflict with any part of the language standard, and would be a better approach to programming applications like this. The only drawback is that this implicitly introduces the overhead of heap manipulation, but it seems that this is hard to avoid in this problem domain. So after giving the matter some thought, I agree with your (and I believe Hyman's) POV on this matter: these declarations should be allowed and implemented via the heap. Ada 95 compilers, by their very nature, have a lot of the infrastructure needed to implement this approach, so this might be a worthwhile addition to Ada 1x.