Adding pointer to container

[tech]

Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

the push back operation can throw so i can leak element if it throws
i thought of doing this but it still has the same problem as e.get()
gets executed first
then if the push back throws i leak the pointer. How to solve?? I
can't use
Boost on this project so the shared_ptr is not an option

function()
{
std::auto_ptr <elemente(new DerivedElement);
m_elements.push_back(e.get());
}

[Ian Collins]

tech wrote:

Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

the push back operation can throw so i can leak element if it throws
i thought of doing this but it still has the same problem as e.get()
gets executed first
then if the push back throws i leak the pointer. How to solve?? I
can't use
Boost on this project so the shared_ptr is not an option

Then roll your own simple shared_ptr pointer.

--
Ian Collins.

[Chris Thomasson]

"tech" <na************@googlemail.comwrote in message
news:01**********************************@z66g2000 hsc.googlegroups.com...

Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

the push back operation can throw so i can leak element if it throws
i thought of doing this but it still has the same problem as e.get()
gets executed first
then if the push back throws i leak the pointer. How to solve?? I
can't use
Boost on this project so the shared_ptr is not an option

function()
{
std::auto_ptr <elemente(new DerivedElement);
m_elements.push_back(e.get());
}

You could do something like:

function()
{
std::auto_ptr <elemente(new DerivedElement);
m_elements.push_back(e.get());
e.release();
}

[tech]

On Jun 11, 12:15*pm, "Chris Thomasson" <[e-mail]:

"tech" <[e-mail] in message

news:01**********************************@z66g2000 hsc.googlegroups.com...

Hi, i have a std::vector of pointers to base classes *say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
* *element* e= new DerivedElement;
* *m_elements.push_back(element);
}

the push back operation can throw so i can leak element if it throws
i thought of doing this but it still has the same problem as e.get()
gets executed first
then if the push back throws i leak the pointer. How to solve?? I
can't use
Boost on this project so the shared_ptr is not an option

function()
{
* std::auto_ptr <elemente(new DerivedElement);
* m_elements.push_back(e.get());
}

You could do something like:

function()
{
* *std::auto_ptr <elemente(new DerivedElement);
* *m_elements.push_back(e.get());
* *e.release();

}- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Replying to Chris Thomasson

std::auto_ptr <elemente(new DerivedElement);
m_elements.push_back(e.get());
e.release();

But this is what i had above without the e.release() at the
bottom, if m_elements.push_back(e.get()); this throws
as the e.get() has already given up the pointer then if the
push back throws surely i will leak the pointer.
Or are you saying the e.get() returns a copy of the pointer
and the auto_ptr still hangs onto it. In that case
it would work and thanks to you

[Paavo Helde]

tech <na************@googlemail.comkirjutas:

Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

the push back operation can throw so i can leak element if it throws
i thought of doing this but it still has the same problem as e.get()
gets executed first
then if the push back throws i leak the pointer. How to solve?? I
can't use
Boost on this project so the shared_ptr is not an option

What about:

void function()
{
m_elements.push_back(NULL);
element*& ref = m_elements.back();
ref = new DerivedElement;
}

HTH
Paavo

[Daniel Pitts]

Alf P. Steinbach wrote:

* Paavo Helde:

>>
What about:

void function()
{
m_elements.push_back(NULL);
element*& ref = m_elements.back();
ref = new DerivedElement;
}

If DerivedElement constructor throws, has already added nullpointer to
vector.
Cheers, & hth.,

- Alf

How about using a try/catch.
void function() {
element * d = new DerivedElement;
try {
m_elements.push_back(d);
} catch (...) {
delete d;
throw;
}
}
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

[Paavo Helde]

"Alf P. Steinbach" <al***@start.nokirjutas:

* Paavo Helde:

>>
What about:

void function()
{
m_elements.push_back(NULL);
element*& ref = m_elements.back();
ref = new DerivedElement;
}

If DerivedElement constructor throws, has already added nullpointer to
vector.

Yes, that's true. What I would do actually in this case, would be to use
the ScopeGuard from Andrei Alexandrescu. This is a case of glueing
together C-style interfaces (raw pointers!) and ScopeGuard comes quite
handy in such situations:

#include <ScopeGuard/ScopeGuard.h>

template <class T>
struct Delete {
void operator()(T *t) const { delete t;}
};
void function()
{
element* e = new DerivedElement;
ScopeGuard guard = MakeGuard(Delete<element>(), e);
m_elements.push_back(e);
guard.Dismiss();
}

But this is only because I have the Delete template and ScopeGuard
includes already in place in the project anyway. std::auto_ptr would work
the same in this case (I suppose, never used myself) and would require
less code in this case.

Regards
Paavo

[Roland Pibinger]

On Sun, 15 Jun 2008 16:30:19 +0200, "Alf P. Steinbach" wrote:

>* Roland Pibinger:

>2. You cannot practically 'handle' Out-Of-Memory (OOM).

Well I think I've written something like that in the past.

Well, some years ago I thought that you could handle OOM ...

>But it's wrong.

Think about an application where the user attempts to load a very big image
file. If allocation fails, a good way to handle it is to inform the user that
sorry, that file was too big. A bad way to handle it would be to terminate...

In case of a file you know the file size in advance and know if the
size is within the limits of your function contract. The Java language
distinguishes between (recoverable) Exceptions and (fatal) Errors.
What can you do after OOM? Can you recover vital memory to proceed?
Hardly in practice. IMO, OOM is a fatal error (like stack overflow and
memory corruption) that should lead to more or less abrupt termination
of the program. This also means that you need not write your code as
if std::bad_alloc were a recoverable exception.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Daniel Pitts]

Roland Pibinger wrote:

On Sun, 15 Jun 2008 16:30:19 +0200, "Alf P. Steinbach" wrote:

>* Roland Pibinger:

>>2. You cannot practically 'handle' Out-Of-Memory (OOM).

Well I think I've written something like that in the past.

Well, some years ago I thought that you could handle OOM ...

>But it's wrong.

Think about an application where the user attempts to load a very big image
file. If allocation fails, a good way to handle it is to inform the user that
sorry, that file was too big. A bad way to handle it would be to terminate...

In case of a file you know the file size in advance and know if the
size is within the limits of your function contract. The Java language
distinguishes between (recoverable) Exceptions and (fatal) Errors.
What can you do after OOM? Can you recover vital memory to proceed?
Hardly in practice. IMO, OOM is a fatal error (like stack overflow and
memory corruption) that should lead to more or less abrupt termination
of the program. This also means that you need not write your code as
if std::bad_alloc were a recoverable exception.

OOM being fatal depends on the context, in both Java *and* C++. In
Java, it is rare, but not unheard-of to recover from an OOM. in C++ it
would probably be easier to recover, since you have more control over
the deallocation of memory than you do in Java.

Like someone said, you can report to the user that the particular
operation took too much memory, and to try another operation instead.
This is better than, say, crashing an entire photo editing session
(probably without saving) because they tried to open one-to-many large
photos.

Now, if it were a small program used in a form of batch processing,
"dieing" on OOM makes more sense, depending on the level of severity of
the operation that can't be completed.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

[Paavo Helde]

rp*****@yahoo.com (Roland Pibinger) kirjutas:

On Wed, 11 Jun 2008 03:36:07 -0700 (PDT), tech rote:

>>Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

You question includes more than one aspect:

1. STL is designend for values only (a.k.a. 'value semantics'), not
objects or pointers to objects. Put simply, STL doesn't work with
pointers.

It seems this is so ridiculous no one has bothered to answer. For innocent
bystanders I just remind that pointers are values in C++.

Paavo

[Kai-Uwe Bux]

Paavo Helde wrote:

rp*****@yahoo.com (Roland Pibinger) kirjutas:

>On Wed, 11 Jun 2008 03:36:07 -0700 (PDT), tech rote:

>>>Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

You question includes more than one aspect:

1. STL is designend for values only (a.k.a. 'value semantics'), not
objects or pointers to objects. Put simply, STL doesn't work with
pointers.

It seems this is so ridiculous no one has bothered to answer. For innocent
bystanders I just remind that pointers are values in C++.

It is true, though, that pointers often require special handling when
dealing with containers. The most basic issue is illustrated by

std::map< char const *, some_type >

By default, the map will compare pointer values and not the strings they
represent. Very likely that is _not_ the desired behavior.
Best

Kai-Uwe Bux

[Paavo Helde]

Kai-Uwe Bux <jk********@gmx.netkirjutas:

Paavo Helde wrote:

>rp*****@yahoo.com (Roland Pibinger) kirjutas:

>>On Wed, 11 Jun 2008 03:36:07 -0700 (PDT), tech rote:
Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

You question includes more than one aspect:

1. STL is designend for values only (a.k.a. 'value semantics'), not
objects or pointers to objects. Put simply, STL doesn't work with
pointers.

It seems this is so ridiculous no one has bothered to answer. For
innocent bystanders I just remind that pointers are values in C++.

It is true, though, that pointers often require special handling when
dealing with containers. The most basic issue is illustrated by

std::map< char const *, some_type >

By default, the map will compare pointer values and not the strings
they represent. Very likely that is _not_ the desired behavior.

If you specify the map keys as pointers, they will be compared as
pointers, that's it. I see nothing specific to STL here.

You could easily instruct the map to use the string comparison (if/when
needed) instead by providing an extra template argument for the map
declaration.

IOW, STL does what it is told to do. It does not attempt to read your
mind. This is a Good Thing IMO.

Regards
Paavo

[Chris Thomasson]

"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:48***************@news.utanet.at...

On Sun, 15 Jun 2008 16:30:19 +0200, "Alf P. Steinbach" wrote:

>>* Roland Pibinger:

>>2. You cannot practically 'handle' Out-Of-Memory (OOM).

Well I think I've written something like that in the past.

Well, some years ago I thought that you could handle OOM ...

>>But it's wrong.

Think about an application where the user attempts to load a very big
image
file. If allocation fails, a good way to handle it is to inform the user
that
sorry, that file was too big. A bad way to handle it would be to
terminate...

In case of a file you know the file size in advance and know if the
size is within the limits of your function contract. The Java language
distinguishes between (recoverable) Exceptions and (fatal) Errors.
What can you do after OOM? Can you recover vital memory to proceed?
Hardly in practice. IMO, OOM is a fatal error (like stack overflow and
memory corruption) that should lead to more or less abrupt termination
of the program. This also means that you need not write your code as
if std::bad_alloc were a recoverable exception.

http://groups.google.com/group/comp....20a821b10a3c72

In C, if malloc returns NULL, what do you do? Well, you could try something
like:

http://groups.google.com/group/comp....7956d31e6ca5cc

OOM is _not_ "always" a _fatal_ error. You can certainly attempt a
recovery...

[Roland Pibinger]

On Sun, 15 Jun 2008 17:31:38 -0700, "Chris Thomasson" wrote:

>In C, if malloc returns NULL, what do you do? Well, you could try something
like:

http://groups.google.com/group/comp....7956d31e6ca5cc

I agree with you: "we are screwed!!! :^o".

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Greg Herlihy]

On Jun 15, 11:02*am, [e-mail] (Roland Pibinger) wrote:

On Sun, 15 Jun 2008 16:30:19 +0200, "Alf P. Steinbach" wrote:

Think about an application where the user attempts to load a very big image
file. If allocation fails, a good way to handle it is to inform the user that
sorry, that file was too big. A bad way to handle it would be to terminate...

In case of a file you know the file size in advance and know if the
size is within the limits of your function contract.

The program could well determine that the file's size does fall within
the limits of its "contract" - but nonetheless have its attempt to
allocate enough memory to open the file - fail. Moreover, one could
imagine that a reasonable contract for a file-opening routine would be
to open the requested file - but to do so only if enough memory is
available. So not every attempted memory allocation has to succeed -
for a program to operate correctly.

The Java language
distinguishes between (recoverable) Exceptions and (fatal) Errors.
What can you do after OOM? Can you recover vital memory to proceed?

There may be no need for the program to recover any memory. After all,
an out-of-memory error does not necessarily mean that the program is
close to exhausting its available memory. In fact, the app has just as
much free memory available ater the failed allocation as it had
beforehand. The only sure conclusion that one draw from an out-of-
memory is: that the amount of memory requested - was too large.

a fatal error (like stack overflow and
memory corruption) that should lead to more or less abrupt termination
of the program. This also means that you need not write your code as
if std::bad_alloc were a recoverable exception.

Stack overflows and memory corruption represent irretrievable loss of
data - data needed for the program to operate correctly. A memory
allocation failure does not represent a similar loss of data; so there
is no reason why a memory allocation failure should necessarily be a
fatal error. On the contrary, for certain types of programs
(particular those that are document-oriented), a well-written program
will anticipate that certain, discretionary memory allocations will
fail - and will therefore handle that possibility, correctly.

Greg

[Nick Keighley]

On 16 Jun, 09:28, Paavo Helde <[e-mail]:

Kai-Uwe Bux <[e-mail]:

Paavo Helde wrote:

Kai-Uwe Bux <[e-mail]:
Paavo Helde wrote:
[e-mail] (Roland Pibinger) kirjutas:
On Wed, 11 Jun 2008 03:36:07 -0700 (PDT), tech rote:

>>>1. STL is designend for values only (a.k.a. 'value semantics'),
not objects or pointers to objects. Put simply, STL doesn't work
with pointers.

really? This is kind of scary to learn...

>>It seems this is so ridiculous no one has bothered to answer. For
innocent bystanders I just remind that pointers are values in C++.

<snip>

[...] this does not justify the claim posted by Mr.
Bibinger: "Put simply, STL doesn't work with pointers.". For example, in
case of polymorphic objects a vector of raw pointers is a quite
reasonable thing to have, especially if the lifetime of the objects is
maintained elsewhere (by GC, for example).

ah good. I was beginning to worry... A vector of pointers to
polymorphic
objects seems like a *very* resonable thing to have!

<snip>
--
Nick Keighley

[James Kanze]

On Jun 16, 2:45 pm, Greg Herlihy <[e-mail]:

On Jun 15, 11:02 am, [e-mail] (Roland Pibinger) wrote:

[...]

a fatal error (like stack overflow and memory corruption)
that should lead to more or less abrupt termination of the
program. This also means that you need not write your code
as if std::bad_alloc were a recoverable exception.

Stack overflows and memory corruption represent irretrievable
loss of data - data needed for the program to operate
correctly.

That's true for memory corruption, but not for stack overflow.
Stack growth is memory allocation; the only real difference
between it and operator new failing is that C++ doesn't provide
any formal means of managing it. Under most Unix, or at least,
under Solaris, there are means if you know what you're doing,
and I've written server applications which were guaranteed not
to crash because of stack overflow---they would respond with an
"insufficient resources" error, just as they would if new
failed.

In practice, for some types of servers, crashing because you
couldn't allocate memory is just not allowed. (For a lot of
others, of course, it *is* what you want to do. It all depends
on the application.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Chris Thomasson]

"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:48***************@news.utanet.at...

On Sun, 15 Jun 2008 17:31:38 -0700, "Chris Thomasson" wrote:

>>In C, if malloc returns NULL, what do you do? Well, you could try
something
like:

http://groups.google.com/group/comp....7956d31e6ca5cc

I agree with you: "we are screwed!!! :^o".

;^)

[Allen]

Paavo Helde wrote:

tech <na************@googlemail.comkirjutas:

>Hi, i have a std::vector of pointers to base classes say
std::vector<element*m_elements;
how do i make the followin exception safe

function()
{
element* e= new DerivedElement;
m_elements.push_back(element);
}

the push back operation can throw so i can leak element if it throws
i thought of doing this but it still has the same problem as e.get()
gets executed first
then if the push back throws i leak the pointer. How to solve?? I
can't use
Boost on this project so the shared_ptr is not an option

What about:

void function()
{
m_elements.push_back(NULL);
element*& ref = m_elements.back();
ref = new DerivedElement;
}

HTH
Paavo

I don't usually handle most OOM problems but what I do in code is use
auto_ptr a bit. Maybe something like this will work:

std::auto_ptr<elemente(new DerivedElement);
m_elements.push_back(e.get());
e.release();

Brian Vanderburg II