tags:

views:

92

answers:

2

I have a project which uses STL a lot. Now I'm working on porting the project to a specific platform which doesn't support exceptions. I can disable exceptions, however I still need to handle STL errors.

Is there any approach to handle STL errors correctly with exceptions disabled? Is there any third party STL implementation which helps with it?

+4  A: 

Possibly an old version of stlport can be configured not to use exceptions. This obviously is non-standard but satisfies your requirement.

Peter G.
+1  A: 

The problem with taking an existing std library coontainer and compiling with exceptions disabled is that the the std container interfaces themselves assume exceptions are enabled. Using exceptions, operator new will throw if it cannot acquire memory, without exceptions, operator new returns a 0 instead, which std containers cannot handle.

One approach is to only use STL algorithms + vector. You can replicate about 95% of what the other containers do using this. The problem is that most STL implementations assume that

v.reserve(v.size()+1);
assert(v.size()+1<=v.capacity());

will never assert (since reserve will throw if there is no memory). To insure this never throws, I have used "fixed capacity" containers, i.e. containers with a capacity fixed at compile time. Basically these are vectors where I pass in a special allocator. Then you can check the max_size() of the container before insertion. Then just avoid using things like at(). For even better predicatbilty, use basic_string instead of vector. This forces you to only store POD types, which never throw when copied or default constructed. Plus memory requirements are easier to compute.

Another approach is to use intrusive containers. These don't throw (outside of misuse of the interface perhaps), since they never acquire memory in the first place.

Lance Diduck