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!feeder1.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news2.arglkargh.de!news.n-ix.net!news.belwue.de!rz.uni-karlsruhe.de!news.gnuher.de!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Wed, 22 Sep 2010 22:25:46 +0200 Message-ID: <87zkv9a5kl.fsf@mid.deneb.enyo.de> References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <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> <1oqw5btmqxu43$.1tzbqy0zcwep8.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: idssi.enyo.de 1285187146 6023 172.17.135.6 (22 Sep 2010 20:25:46 GMT) X-Complaints-To: news@enyo.de Cancel-Lock: sha1:2q8w21/8voOrFJ1C0oFS0UjIPug= Xref: g2news1.google.com comp.lang.ada:14196 Date: 2010-09-22T22:25:46+02:00 List-Id: * Dmitry A. Kazakov: > On Wed, 22 Sep 2010 21:51:16 +0200, Florian Weimer wrote: >> It's hard to beat the C++ type system in terms of expressiveness. > > As someone designing component libraries for both Ada and C++ I would say > that the C++'s type system is far behind Ada. Though C++ has some > substantial and evident advantages over Ada, e.g. proper constructors, > proper MI, partial inheritance from concrete types, that does not pay off, > because the rest is too bad. > > At least to me, it is impossible to achieve consistency and clearness of > design any close to what can be done in Ada. Looking at C++ class libraries > designed by other people assures me that I am not alone. I don't doubt that this has been your experience, but this in no way contradicts that the C++ type system is way more expressive than Ada's. It's probably the other way round: C++ is too expressive, and it is difficult to find the right amount of type-level programming. >>> 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. > > Stack/heap allocation refer to a memory management policy rather than > physical location. This boundary is very sharp: the stack policy presumes > two important constraints: 1. LIFO ordering, 2. Ownership by the task. Neither is true if you can create tasks dynamically. Instead of using an allocator, you just wrap the object to be created in a task, where you put it on the stack. In effect, you have bypassed both constraints (because the owner is not you, but some other task).