C + + portability and cross-platform development [3]: Exception handling

The previous post "grammar" due to space is limited, did not have time to talk about the anomaly, and now the exception related to the part of the separate to say.

★ Beware of new Allocate memory failed

The code generated by the earlier old compiler will return a null pointer if new fails. I used to use the Borland C + + 3.1 seems to be the case, now this compiler should be rare. If you're using a compiler that still behaves like this, you're in for a bad time. You can consider overloading the new operator to throw a Bad_alloc exception to facilitate exception handling.

A slightly newer compiler does not simply return a null pointer. When the new operator discovers the memory shortage, it should call the New_handler function (the prototype is typedef void (*new_handler) ()), as specified in the standard (see 03 Standard 18.4.2 section). The standard recommends that the New_handler function do the following three things: 1, try to get more memory, 2, throw Bad_alloc exception, 3, call abort () or exit () quit the process. Since the New_handler function can be reset (by calling Set_new_handler), it is possible that the above behavior is available.

To sum up, the new allocation of memory failed, there may be three possible: 1, return null pointer, 2, throw an exception, 3, the process immediately terminated. If you want your code to be better ported, you have to consider all three of them.

★ Use abnormal specifications with caution

Exception specifications In my opinion is not a good thing, do not believe you can go to see "C + + coding Standards-101 Rules, guidelines & best Practices" 75th. (Specific disadvantages after a special C + + exception and error handling of the post to chat) back to the standard (see 03 Standard 18.6.2 chapters), if a function thrown outside the exception is not included in the function of the exception specification, then should call Unexcepted (). But not all compiler-generated code complies with the standard (for example, some versions of the VC compiler). If the compiler you need to support does not behave the same on the exception specification, consider removing the exception specification declaration.

★ Do not throw exceptions across modules

The module mentioned here refers to the dynamic library. If your program contains more than one dynamic library, do not throw the exception out of the module's exported function. After all, there is no ABI standard for C + + (it is not expected to happen in the future), and throwing exceptions across modules can be a lot of unpredictable behavior.

★ Do not use structured exception handling (SEH)

If you've never heard of Seh, just skip the paragraph if I don't say so. If you've been used to using SEH, get rid of the habit before you plan to write Cross-platform code. Code that contains SEH can only be compiled on the Windows platform, and certainly not cross-platform.

★ About catch (...)

In a sense, catch (...) Statements can only capture the exception types of C + +, and are powerless against non-C + + exceptions such as access violations, except 0 errors. But in some cases (such as some VC compilers), such as access violations, except 0 errors can also be catch (...) Capture. So, if you want code portability to be good, you can't rely on the above catch (...) in your program logic. 's behavior.

Next post, ready to talk about "hardware-related Cross-platform issues".

Original address: http://program-think.blogspot.com/