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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Preventing type extensions
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
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>
 <epkb3s8dfxk0$.1qdvo5vg2fsgh.dlg@40tude.net>
 <8f6cceFrv2U1@mid.individual.net>
 <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com>
 <i6m45c$gjp$2@news.eternal-september.org>
 <c75a88c5-1d51-4342-904a-743e41adeb7f@k9g2000vbo.googlegroups.com>
 <i7afm3$dn8$1@news.eternal-september.org>
 <a9a93110-c5a1-41cb-b36a-0e8da7f4cacf@q26g2000vbn.googlegroups.com>
 <i7air8$q3k$1@news.eternal-september.org>
 <81799aab-a2e8-4390-8f42-abceaa5fc032@m1g2000vbh.googlegroups.com>
 <i7cd4n$9tj$1@news.eternal-september.org>
 <5c0d7798-ba09-4bd0-a28f-f1b028cce927@y3g2000vbm.googlegroups.com>
 <87r5gl8tky.fsf@ludovic-brenta.org> <8762xxd0az.fsf@mid.deneb.enyo.de>
Date: Wed, 22 Sep 2010 22:14:12 +0200
Message-ID: <1oqw5btmqxu43$.1tzbqy0zcwep8.dlg@40tude.net>
NNTP-Posting-Date: 22 Sep 2010 22:14:10 CEST
NNTP-Posting-Host: a5b1e1db.newsspool4.arcor-online.net
X-Trace: 
 DXC=OW>iTl>QLS^U6b:FjPaGjQ4IUK<Cl32<Q4Fo<]lROoRQ8kF<OcfhCO[72S`E2=fYY\[6LHn;2LCV^[<mhadbfdU[]:RN;Ek89[V@3fUYg;Skg\
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:14194
Date: 2010-09-22T22:14:10+02:00
List-Id: <comp.lang.ada>

On Wed, 22 Sep 2010 21:51:16 +0200, Florian Weimer wrote:

> * Ludovic Brenta:
> 
> 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.

>> 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de