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-7-bit Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!feeder.erje.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 22:16:36 +0200 Organization: A noiseless patient Spider Message-ID: <87mxr98rff.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> <87r5gl8tky.fsf@ludovic-brenta.org> <8762xxd0az.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 22 Sep 2010 20:16:35 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="Kwa66aPhPQWrn7Sp6Y7BLw"; logging-data="6588"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TyNRB89MMU6PXLIT5i7sq" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:rOKaPm6t8rPNn0jYzDAgCOJntDE= sha1:oH9jjQxczi/5zjzOJ04bCZNoWds= Xref: g2news1.google.com comp.lang.ada:14195 Date: 2010-09-22T22:16:36+02:00 List-Id: Florian Weimer writes on comp.lang.ada: > * Ludovic Brenta: > >> 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++ > > Iterators are examples of pool-specific allocators in C++. How so? IIUC, iterators are not even a language construct, only an idiom in the standard library. > It's also common to define your own pointer types in C++. Do you mean that typedef T* T_Pointer; is common? > It's hard to beat the C++ type system in terms of expressiveness. I disagree; I just showed the opposite in my previous post. C++ does not have specific pointer types, for example; only class-wide ones. >> 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? > > I don't think this would provide useful information. Tasks blur the > boundary between heap and stack allocation. Insofar as each new task creates a stack from the heap of the environment task, yes. But the Ravenscar profile forbids this, so the "access aliased" feature might be useful in this context, which happens to be the context where certification is needed. -- Ludovic Brenta.