std containers and allocators.

[Andy Venikov]

Is there a way to change standard containers' behavior
to expect a 0 when allocation fails (same way you can
change operator new's behavior to return null by passing
std::nothrow) ?

In my environment I can't use exceptions. I can't use
standard allocators either (embedded, you get the picture).
I recompiled STLPort with _no_exceptions, but when my
allocator failed (returned 0) the whole thing crashed.
My guess is that recompiling with "no exceptions" did
not change the behavior and it still references 0.
Is there a standard way to do it?

Thank you,
Andy.

 

[Howard Hinnant]

Is there a way to change standard containers' behavior
to expect a 0 when allocation fails (same way you can
change operator new's behavior to return null by passing
std::nothrow) ?

In my environment I can't use exceptions. I can't use
standard allocators either (embedded, you get the picture).
I recompiled STLPort with _no_exceptions, but when my
allocator failed (returned 0) the whole thing crashed.
My guess is that recompiling with "no exceptions" did
not change the behavior and it still references 0.
Is there a standard way to do it?

No.

What would you like the container to do when its allocator returns 0?

-Howard

 

[Andy Venikov]

Well, for insert(), the return could point to map::end.
For instance.

 

[Howard Hinnant]

Well, for insert(), the return could point to map::end.
For instance.

<nod> And push_back? Constructors?

I've done a lot of work on the Metrowerks/Freescale implementation of
the std::lib to make it work well in embedded environments (reducing
heap and code size requirements). And it does have a no-exceptions
mode. The reason I'm asking what your expectations are is to find out
if I could do something better than what I'm currently doing.

On allocation failure when exceptions are turned off, our std::allocator
will call a user-replaceable error function. However the containers are
not prepared for this function to return. The expectation is that in
this mode, running out of heap is a bug to be fixed before release, as
opposed to an unexpected run time event that can be handled (handled
short of rebooting the program). If the program needs to view this
event as the latter, I can think of no better way to do so than
exceptions. However I am open to suggestions.

-Howard

 

[Andy Venikov]

<nod> And push_back? Constructors?
Don't forget operator [] for maps, that one may be
the trickiest

Yeah, I'm aware of the problem. I was just dumb struck
hitting it in the real life. It looks like the STL design is really
not compatible (or hardly compatible) with exceptions-free
environments.

One way to go around the problem I'm still contemplating, is to
design the custom allocator in such a way that it always keeps
extra memory enough for several elements after the official
memory has bee exhausted, so that the container itself doesn't
try to reference bad pointers, but the allocator will flag this event.
The flag will have to be querried by the user of the container.
Of course there's a lot of problems with this approach.
First, the allocator now relies on the container's user to querry the
allocator status and to free newly added element in case of a failure.
Second, it requires the container's user to know something about the
custom allocator and how to querry for the status. Third, it doesn't
solve the case when the container does bulk allocation.
But still, it's a way.

Thanks,
Andy.