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,6b1a1ed8b075945
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Allocators and exceptions
From: Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>
In-Reply-To: <1189537626.913207.116840@e34g2000pro.googlegroups.com>
References: <1189323618.588340.87180@o80g2000hse.googlegroups.com>
	 <jvREi.80243$ax1.52638@bgtnsc05-news.ops.worldnet.att.net>
	 <1189369871.672082.162750@50g2000hsm.googlegroups.com>
	 <kv25hx961chk.5kg3us0ye06y.dlg@40tude.net>
	 <1189460936.295604.143720@r29g2000hsg.googlegroups.com>
	 <ixr8l1ty6phe$.stdgh66rlsrl$.dlg@40tude.net>
	 <1189502377.626510.172690@22g2000hsm.googlegroups.com>
	 <5rjahxfvhazu.bol1ilmh6uew$.dlg@40tude.net>
	 <1189537626.913207.116840@e34g2000pro.googlegroups.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1189551376.12652.36.camel@kartoffel>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Date: Wed, 12 Sep 2007 00:56:16 +0200
Organization: Arcor
NNTP-Posting-Date: 12 Sep 2007 00:56:30 CEST
NNTP-Posting-Host: cb765153.newsspool3.arcor-online.net
X-Trace: 
 DXC=0OaegP\d7fS=>bdbdS?M0YMcF=Q^Z^V3X4Fo<]lROoRQ^;5]aA^R6>RL]_QDT8B6i_=kbmW`a1fGWC`2T@AUZfC[nBA<D_dhGRZ
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:1896
Date: 2007-09-12T00:56:30+02:00
List-Id: <comp.lang.ada>

On Tue, 2007-09-11 at 12:07 -0700, Maciej Sobczak wrote:

> But... did I mention that C++ handles this issue correctly? ;-)
> And no, it does not have any super-capable access types. A little bit
> smarter allocator is enough.

C++ doesn't seem to handle deallocation etc. of sibling components
either, so I'm not sure I understand. Isn't this a rather special
case you are describing?
 Should the following be excluded from consideration? (The program
quickly claims all available memory, as I would have expected; any
pointers to what should I read to learn how this can be simply
prevented in C++?)


class T {
   int c;
   int *x;
public:
   T(int init) {
      x = new int[1024];
      if (init < 1) { throw "Constraint_Error"; }
      c = init;
   }
   ~T() {
      delete[] x;
   }
};

typedef T* T_access;

int main()
{
   T_access ptr;

   while (1) {
      try {
         ptr = new T(-5); 
         delete ptr;
      } catch (...) {
         // all is well?
      }
   }
   return 0;
}