> We really do need precise descriptions of the problems so we can avoid them.
Initialization of objects with static storage duration typically get a bad wrap for two main reasons: (1) each toolchain implements them differently (but typically by storing initialization thunks in a table that is walked by the C++RT before entry to 'main'), which may lead to subtle differences when compiling for different platforms and (2) there is no guaranteed initialization order across translation unit boundaries. (1) is just a fact of multi-platform development. (2) is a bit more interesting. Consider two translation units 'a.cpp' and 'b.cpp': // a.cpp T { T() {} }; ... static T obj1; // b.cpp S { S() {} }; ... static S obj2; When 'obj1' and 'obj2' get linked into the final image there are no guarantees on whose constructor (T::T or S::S) will be called first. Sometimes folks write code where this initialization order matters. It may cause strange behavior at run-time that is hard to pin down. This may not be a problem in the LLVM code base, but it is the typical problem that C++ devs run into with initialization of objects with static storage duration. Also related to reduced code size with C++ I was wondering whether or not anyone has explored using the ability of some toolchains to remove unused code and data? In GCC this can be enabled by compiling with '-ffunction-sections' and '-fdata-sections' and linking with '--gc-sections'. In MS VC++ you can compile with '/Gy' and link with '/OPT'. This feature can lead to size reductions sometimes with C++ due to things like template instantation causing multiple copies of the same function to be linked in. I played around with compiling CPython with this (gcc + Darwin) and saw about a 200K size drop. I want to try compiling all of U-S (e.g. including LLVM) with these options next. Thanks, -- Meador
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com