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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1901f265c928a511 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Wed, 23 Jun 2004 14:47:33 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <40BDBBFA.2020203@noplace.com> <1087475285.166449@master.nyc.kbcfp.com> <2jlepqF12qbb6U1@uni-berlin.de> <1774424.VSnnNmZCKX@linux1.krischik.com> Subject: Re: new revision ada Date: Wed, 23 Jun 2004 14:47:58 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-vFvpqZpeIyqKnctyFkoao2q5YpvE+mcJLD5q8yvgvqt1agDSRpgnApjGvQQUbuWptfahIaV/lsrtWKu!LHJAH74kRpjhQVASZSebc81m/J4+JdzhyzY+2TXY5xChx6Z+1gW/MceRz2gBxcgRbDmahOyMVPHO X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: g2news1.google.com comp.lang.ada:1821 Date: 2004-06-23T14:47:58-05:00 List-Id: "Brian May" wrote in message news:sa4acyulwtc.fsf@snoopy.apana.org.au... ... > Similarly, the booch component model no doubt will require allocation > of additional memory, too. > > But what if the exception that is being processed is of a direct > result of a out of memory error? (obviously I am assuming this is on > some system, eg. embedded systems, that detects out of memory errors > before it is too late). Even if it isn't the out of memory exception > itself, a program may need to throw a new exception in response to an > out of memory error. No doubt multiple threads may get out of memory > errors simultaneously too, as they probably are sharing the same > memory pool. Given that you're talking about passing an unknown amount of memory along with the exception (since it depends on which exception you raise, you can hardly pre-allocate it), I would think that raising an exception in your model would have to allocate memory. The reason for the 200 character limit on the exception message string is simply so that memory doesn't need to be allocated when raising an exception. (Of course, an implementation could allocate a fixed amount of space for exception handling, and fall back to allocating memory only if it doesn't fit -- but that doesn't eliminate the original problem.) In any case, the ARG looked at ways to extend the exception model, and ultimately decided that none of them looked very appealing. They were complex or incompatible, and ultimately the issue was dropped because other areas were more important (limited with, interfaces, Ravenscar, limited constructors, etc.) Recently, we decided to lift some of the restrictions on tagged type derivation. That would allow exceptions to be a kind of tagged type (with the Ada 95 restrictions, you wouldn't have been able to declare exceptions in nested scopes -- which of course would have been too incompatible to consider). Thus, a clean solution based on type extension now would be possible. However, we're nearing the end of the process, and we have been strictly enforcing the rules about not reopening closed AIs. Moreover, WG9 just approved the scope of the Amendment, so adding in anything at this late date would require extordinary action. One of the reasons that we stopped working on it was that putting an id of some sort in the exception message string is sufficient in virtually all cases. It certainly isn't real clean, but as Tom demonstrated, you can wrap the entire thing in a generic package and not have to see any of the dirty details. While having mutually dependent types in multiple packages, or multiple interface inheritance, or a constructor for a limited object, is simply impossible in Ada 95. BTW, look at ada-auth.org for the current state of the project, especially in the "Grab Bag" section. I haven't updated that yet for the results of the Palma meeting, but that will be done soon. Randy Brukardt ARG Editor Editor, ISO/IEC 8652:AMD 1