Re: Allocators and exceptions

[Maciej Sobczak <see.my.homepage@gmail.com>]

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/