STLPort - exception handling

STLPort for OpenWatcom

Exception handling notes

1. Exception handling

Unfortunately all supported Watcom compilers fail to pass exception test suite when compiled with standard compile options.

Observations:

test suite crashes with access violation,
time to crash depends on number of exceptions thrown during test run: when number of iterations per test is decresed more tests pass and vice-versa,
symptoms suggests that Watcom destroys MORE objects during stack unwinding then it created (this is my guess only...), it looks that OpenWatcom can throw limited number of exception correctly.

Workaround:

You can use the -d2i option to make exception handling usable (this was tested with OpenWatcom 1.3 only). The -d2i makes compiler to emit ALL inline functions as standard function calls, which is of course with some performance penalty.

Altough -d2i debug option by default disables all optimisations, you can re-enable them by placing -o* options AFTER the -d2i.

This example enable speed optimisation:

wpp386 -d2i -ot <remaining_arguments>

In order to get rid of debugging information from the final executable you should use the strip utility supplied with Watcom or disable emiting them at link stage.

1.1. Watcom's native exception headers

For now only the except.h is used in STLport.

Standard exceptions header (exceptio.h) cannot be used due to hack in it: the stream class is redefined with primitive stub, which clashes with the STLport streams; STLPort's standard exception classes are used instead.