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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,591cbead201d7f34 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!feeder3.cambrium.nl!feed.tweaknews.nl!newsfeed.kamp.net!newsfeed.kamp.net!newsfeed.straub-nv.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Prohibiting dynamic allocation for the given type Date: Wed, 19 Mar 2008 18:08:34 -0500 Organization: Jacob's private Usenet server Message-ID: References: <83335709-e099-416b-9967-5ab6aa0aea11@i12g2000prf.googlegroups.com> <47E11F35.5000900@obry.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1205968131 15904 69.95.181.76 (19 Mar 2008 23:08:51 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 19 Mar 2008 23:08:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:20496 Date: 2008-03-19T18:08:34-05:00 List-Id: "Pascal Obry" wrote in message news:47E11F35.5000900@obry.net... > Maciej Sobczak a �crit : > > Is it possible to "prohibit" dynamic allocation for the given type? > > Just a quick idea... What about using a storage pool which raises a > program_error when using it. Then apply this storage pool to the type > where you want to forbid dynamic allocation. Shouldn't something like > this work? If this did work (it doesn't, as mentioned by many), it would be easier to simply specify 'Storage_Pool to be 0, which prohibits allocation. But the whole idea seems dubious to me. Most types (ADTs) ought to be constructed so that the client can use them in whatever way they want - that is, they shouldn't only work in a single way. (Non-ADT types aren't really interesting, as they usually are hidden in a package body, or are some sort of discrete type for which nothing very interesting can happen.) Moreover, for types where lifetime matters (like types with automatically released locks), *how* the object is created is not really relevant. An object allocated from a local access type, or even one allocated from a global access type that is later freed with Unchecked_Deallocation both would meet the requirement of a limited lifetime. Which is all to say that Ada doesn't really have a way to express lifetime of types (at least of ADT types), and thus you have to fall back on usage rules as part of the documentation of the ADT. As someone else mentioned, someone who uses a lock in a global context doesn't understand the purpose of the type very well... More generally, there are always going to be things that cannot be statically expressed in a programming language. This seems like one of them for Ada. Randy.