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,UTF8 Path: g2news1.google.com!news3.google.com!news4.google.com!feeder.news-service.com!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Wed, 22 Sep 2010 21:30:05 +0200 Organization: A noiseless patient Spider Message-ID: <87r5gl8tky.fsf@ludovic-brenta.org> 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> <81799aab-a2e8-4390-8f42-abceaa5fc032@m1g2000vbh.googlegroups.com> <5c0d7798-ba09-4bd0-a28f-f1b028cce927@y3g2000vbm.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 22 Sep 2010 19:30:06 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="Kwa66aPhPQWrn7Sp6Y7BLw"; logging-data="28361"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19RIgtcqtG9Q0/T+MuNWv3x" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:qCs7kMs/s4uUpwbLT0vQqevL1SQ= sha1:aKGAamKHIjvY/8dI2NeKqNrr3v0= Xref: g2news1.google.com comp.lang.ada:14191 Date: 2010-09-22T21:30:05+02:00 List-Id: Cyrille Comar writes on comp.lang.ada: > On Sep 22, 10:01 am, "J-P. Rosen" wrote: >> Ada is unique in that you can have true methods (aka primitive >> operations) that belong to a specific type, and class-wide operations >> that are unique for a whole subtree. > > what is unique about that? In C++ you also have methods and other > subprograms taking a class as a parameter. I don't see any fundamental > difference between the latter and what you call "classwide > operations" (and by which I suppose you simply mean a subprogram with > classwide parameters, right?) > >> Because they are unique, coverage testing drops from N to 1. > > No idea of what you are talking about... I suppose this is a reference > to what OOTiA calls "pessimistic testing" but I still don't understand > your claim. > >>>> For inlining, I was referring to the corresponding chapter of OOTiA >> >>> That's what I supposed.... There is little to be reused in that part >>> of the document... >> >> I agree that there is nothing here specific to OO. However, inlining is >> a problem when you need level A (code) coverage, because it creates >> often dead code or hard to test paths. > > Level A requires statements+mcdc coverage. inlining doesn't impact any > of those coverage metrics. It might impact object coverage, which can > be used as an alternative method (with additional work to show > equivalene with the aboce mentioned metrics) My understanding (from the days when I worked at Barco Avionics) was that level A requires full path (MC/DC) coverage at the object level, not the source level. This includes proof of absence of dead object code. The only practical way to achieve this is source-level MC/DC coverage *plus* complete source-to-object traceability, including proof of absence of object code not corresponding to any source. In fact, this is the essential difference between levels A and B. > and it might also impact > source-to-object traceability analysis. This is just a potentially > complicating factor that you have to take into account when you make > your plans and define your coding standard... Oh, you said "just"! >>> It is not the case. There is very little of OOTiA left in the OO >>> supplement. It was an input to the process but the subcommittee soon >>> realized that little could be reused. For one thing, most of the >>> material is at the level of "coding standard" material and thus not at >>> the right level for a standard such as DO-178. >> >> Sure. I would expect DO-178C to be more objectives-driven, while the >> OOTiA was more about processes and issues. Can't OOTiA be considered as >> a document that explores possible ways to achieve the objectives of DO-178C? > > not really. OOTiA raised all the issues that people had in mind when > the document was written. Most of the issues come from either > - people from the certif community not knowing OO very well (the > fear factor) > - people from the OO community not mastering DO-178 And people not knowing Ada and thinking that the only OO language was C++. I totally agree with Jean-Pierre that Ada has made a very important contribution to OO technology in distinguishing class-wide from specific types; C++ does not have class-wide types, it only has class-wide *pointer* (and reference) types; and it conversely does not have specific pointer or reference types. Consider: type T is tagged private; function Construct return T'Class; type T_Access is access all T; -- no equivalent in C++ type T_Class_Access is access all T'Class; -- equivalent to T* in C++ Object : T'Class := Construct; -- no equivalent in C++; you need a pointer Another area where Ada helps certification is where it distinguishes pool-specific from general access types. C and C++ are both completely helpless in this respect. Consider: type T_Access is access T'Class; -- no equivalent in C++ type T_General_Access is access all T'Class; -- equivalent to T* in C++ Hey, just a wild idea: how about type T_Stack_Access is access aliased T; which indicates that access values of this type can *only* designate aliased objects that are on the stack, and never on the heap? -- Ludovic Brenta.