Portability and cross-platform development of C ++ [3]: Exception Handling

In the previous post, due to limited space, I had no time to talk about exceptions. Now I want to explain the exceptions separately.

★Be careful when memory allocation fails.
Early old-fashioned compiler-generated code returns a null pointer if new fails. Borland C ++
3.1 seems to be like this, and this compiler should be rare now. If the compiler you are currently using has such behavior, you will be miserable. You can consider overloading the new operator to throw
Bad_alloc exception to facilitate exception handling.
A slightly newer compiler does not simply return NULL pointers. When the new operator finds that the memory is in a hurry, follow the Standard Rules
(See section 18.4.2 of the c ++ 03 standard). It should call the new_handler function (prototype: typedef void
(* New_handler )();). The new_handler function is recommended to do the following three things: 1. Try to increase the memory; 2. Throw the bad_alloc exception; 3. call abort () or exit () to exit the process. Because the new_handler function can be reset (by calling set_new_handler ),
Therefore, all the above actions can be performed.
To sum up, the memory allocation of new may fail in three ways: 1. NULL pointer is returned; 2. An exception is thrown; 3. The process is terminated immediately. If you want your code to be highly portable, you have to consider all three cases.

★Use abnormal specifications with caution
Exception specification is not a good thing for me. If you don't believe it, go to C ++ coding standards-101 rules, guidelines
& Best
75th in practices. (In the future, I will talk about the specific disadvantages of C ++ exception and error handling.) back to the truth, follow the standards (see Chapter 18.6.2 of 03 Standard)
Section). If an exception thrown by a function is not included in the exception specification of the function, call unexcepted (). But not all the code generated by the compiler follows the standard (for example
Some versions of the VC compiler ). If you need to support the inconsistent behavior of the compiler on the exception specification, consider removing the exception specification declaration.

★Do not throw an exception across modules.
The module mentioned here refers to the dynamic library. If your package contains multiple dynamic libraries, do not throw exceptions out of the export function of the module. After all, C ++ does not have the ABI standard yet (it is estimated that there may not be one in the future), and many unpredictable behaviors may occur when an exception is thrown across modules.

★Do not use structured exception handling (seh)
If you have never heard of Seh, skip it. If you used to use seh before, you should get rid of this habit before writing cross-platform code. Code containing seh can only be compiled on Windows, and cannot be cross-platform.

★Catch (...)
The catch (...) statement can only capture the exception type of C ++. It is powerless for non-C ++ exceptions such as access violation and division by zero errors. But in some cases (for example, some VC Compilation
Such as access violation and division by zero errors can also be captured by catch. Therefore, if you want code portability to be good, you cannot rely on the above catch (...) behavior in the program logic.

Next post, I want to talk about "Hardware-related cross-platform problems ".

Http://program-think.blogspot.com/2009/01/cxx-cross-platform-develop-3-exception.html