Emil Dotchevski wrote:
As far as "deadstripping" code - this has indeed been a big problem - especially in release mode. I've referred to it as overzealous optimization.
It isn't overzealous -- it's within the specifications of the standard, whether you like it or not.
Chapter and verse? (Given the above argument that dynamic initialization must happen first.)
The standard does not deal with deadstripping but to me it's obvious that if A) the compiler is not required to initialize a namespace-scope object until a function from its translation unit is called, and B) no function from that translation unit is called, the obvious conclusion is that the object will never be initialized and therefore can be safely deadstripped.
If I recal, the "dead stripping" occured even if a function was called from the class. test_exported calls the constructor for a derived class (via new) but doesn't explicitly call any "serialize" function. WIthout extra "help", the program won't link in release mode. I called this "overzealous optimization". I'm not sure we're referring to the same thing here. I solved it by marking the dropped functions with "_export" so that the linker wouldn't know they were never called. Again, I'm not sure we're referring to the same thing here. Then there's the question of an inline constructor. Its not at all clear to me what translation unit - if any it belongs. Note that the problem I've been referring to even occurs in the absense of export so - I don't think this (at least this particular problem) is a C++ standards issue. Except perhaps to say the C++ doesn't even address things like dynamic export of functions which is very common in windows programs at least. Robert Ramey