Compatibilities

摘要

Guidelines for Module Boundaries What applies to functions applies in particular to the boundary of any module (nonsource unit of release; for example, shared library, DLL, or object file), which tends to be where you have the least amount of control over perfect build agreement with all possible callers. In a module, if you want to do any of the following in an externally accessible function: 1.Mention a user-defined type in the module's external interface (for example, as a parameter public or exported API). 2. Allocate memory in the module and deallocate it outside the module, or vice versa. (See Item 60 of [1].) 3. Allow an exception to propagate out of the module to a caller. (See Item 62 of [1].) then you must be able to guarantee that the module and all of the code that will ever call it will be compiled using the same compiler and compatible compiler switch settings. Just using the same compiler isn't enough: Popular compilers can and do generate incompatible code for all three of the above if you throw different switch settings, You also have to use the same Standard Library implementation, including the same version, if any Standard Library facilities are mentioned in an externally visible functions signature or are shared outside the module.