> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
