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-Thread: 103376,29d8139471e3f53e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Tue, 21 Sep 2010 17:26:25 +0200 Organization: Adalog Message-ID: References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <874odv9npv.fsf@ludovic-brenta.org> <87y6b7cedd.fsf@mid.deneb.enyo.de> <66a3704c-54f9-4f04-8860-aa12f516134b@t3g2000vbb.googlegroups.com> <87d3sib44t.fsf@mid.deneb.enyo.de> <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net> <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net> <8f6cceFrv2U1@mid.individual.net> <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 21 Sep 2010 15:26:32 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="NnUeFCqNZ0jpIYDukgk1kA"; logging-data="26740"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HzcGh2I9cx27o9hHP/UZt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 In-Reply-To: Cancel-Lock: sha1:pCg7HDiWBu+iRkTusVjRJVAsbrs= Xref: g2news1.google.com comp.lang.ada:14174 Date: 2010-09-21T17:26:25+02:00 List-Id: Le 21/09/2010 17:02, Cyrille a �crit : > which strategy? you seem to be referring implicitly to a document that > I'm not aware of. I'm not aware of any "serious" arguments against > inlining which is simply a compiler technique for improving > performance. The one that forbids redispatching in favour of class-wide operations. This can be done only in Ada, and can be a big plus for testing. For inlining, I was referring to the corresponding chapter of OOTiA >> The workshop at the conference is the starting point for a document that >> will define appropriate restrictions ("Fairfax profile"). Starting such >> an effort during an Ada conference seems absolutely appropriate. > > It seems a bit early, DO-178C hasn't been published yet and people > participating to such an effort will need time to access it once it is > published and understand it. I couldn't get my hands on DO-178C, but form what I heard it will be based (at least on the principles) on the work of OOTiA, which originated from the C++ community and ignores the possibilities offered by class-wide types - that was the starting point of this thread. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00