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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no 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!postnews.google.com!k79g2000hse.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Allocators and exceptions
Date: Wed, 12 Sep 2007 05:36:54 -0700
Organization: http://groups.google.com
Message-ID: <1189600614.629447.86470@k79g2000hse.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>
   <1189551376.12652.36.camel@kartoffel>
NNTP-Posting-Host: 137.138.37.241
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Trace: posting.google.com 1189600614 29716 127.0.0.1 (12 Sep 2007 12:36:54
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 12 Sep 2007 12:36:54 +0000 (UTC)
In-Reply-To: <1189551376.12652.36.camel@kartoffel>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.0.12) Gecko/20070724 Red Hat/1.5.0.12-0.3.slc3
 Firefox/1.5.0.12,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: k79g2000hse.googlegroups.com; posting-host=137.138.37.241;
   posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0
Xref: g2news2.google.com comp.lang.ada:1908
Date: 2007-09-12T05:36:54-07:00
List-Id: <comp.lang.ada>

On 12 Wrz, 00:56, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
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.

It does. In case of exception the already constructed components are
rolled back. This works for components of array as well.

> 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"; }

Yes, this is very bad coding. We call it "C with classes" to clearly
distinguish it from C++.

Try this:

class T
{
   int c;
   vector<int> x;
public:
   T(int init)
   {
      x.resize(1024);
      if (init < 1) { throw "Constraint_Error"; }
   }

   // note: no destructor needed
};

Alternatively:

class T
{
   int c;
   scoped_array<int> x;
public:
   T(int init)
   {
      x = new int[1024];
      if (...
...

And so on.

C++ will roll-back all already created components by calling their
destructors. In your initial ("C with classes") example, there were
two components:

int c;
int *x;

Both will be properly rolled back, which here means do nothing - these
are fundamental types.

Use smarter types to get smarter rollback.
Use C++ instead of "C with classes" and the difference will be
significant.

Note that with smarter types the code is actually shorter (no explicit
destructor needed). Less coding, less bugs, ... ;-)

--
Maciej Sobczak
http://www.msobczak.com/