Is there any interest in a base class which prevents construction during the static initialization phase?
Hello, Because the order of static initialization is undefined, numerous difficult to detect problems can arise when multiple objects are initialized during the static initialization phase. This base class would guarantee that a class will never be unintentionally constructed during static initialization. This is the same philosophy behind how boost::noncopyable guarantees that a class will never be unintentionally copied. Usage would appear as follows: #include <submission/nonstaticinitializable.hpp> #include <boost/noncopyable.hpp> namespace { class Foo : private submission::nonstaticinitializable, private boost::noncopyable { public: Foo() : nonstaticinitializable() {} }; // Foo } // unnamed namespace Foo fooThatWillAssert; // This instance asserts during static initialization int main() { nonstaticinitializable::enable_initialization(); // Indicates that static initialization is complete. Foo foo; // This instance initializes successfully after static initialization. return 0; } // main What does Boost think about submission::nonstaticinitializable (I chose the name to mirror noncopyable)? Thank you, Ben Robinson
On Sun, Jun 12, 2011 at 4:51 PM, Ben Robinson <icaretaker@gmail.com> wrote:
Hello,
Because the order of static initialization is undefined, numerous difficult to detect problems can arise when multiple objects are initialized during the static initialization phase. This base class would guarantee that a class will never be unintentionally constructed during static initialization. This is the same philosophy behind how boost::noncopyable guarantees that a class will never be unintentionally copied.
What you probably mean is "initialization of objects with static storage duration", which can be static and dynamic. All such objects are first zero initialized. Then the ones that are initialized with a constant expression are initialized, and this concludes the static initialization phase. Then the dynamic initialization phase follows. Only the dynamic initialization phase can cause problems. However, the dynamic initialization phase can cause problems with any object that uses it. That is, whether or not a compile error is induced should only depend on whether or not a given object with static storage duration is initialized during the dynamic initialization phase. Deriving or not deriving from nonstaticinitializable doesn't seem to have anything to do with this. Don't get me wrong, I agree that using objects with static storage duration that are initialized dynamically is the source of many problems, but it seems like it makes more sense to detect and report such initialization with a lint-type utility rather than relying on a programmer to derive from a type. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Jun 12, 2011, at 4:51 PM, Ben Robinson wrote:
Because the order of static initialization is undefined, numerous difficult to detect problems can arise when multiple objects are initialized during the static initialization phase. This base class would guarantee that a class will never be unintentionally constructed during static initialization. This is the same philosophy behind how boost::noncopyable guarantees that a class will never be unintentionally copied.
int main() { nonstaticinitializable::enable_initialization(); // Indicates that static initialization is complete. Foo foo; // This instance initializes successfully after static initialization. return 0; } // main
What does Boost think about submission::nonstaticinitializable (I chose the name to mirror noncopyable)?
The requirement to modify main() is sufficiently burdensome that I probably wouldn't use this technique, though I admit the failure mode is an assertion failure that's easy to fix. But also consider that the unit defining main() might be written in C. Josh
participants (3)
-
Ben Robinson -
Emil Dotchevski -
Joshua Juran