3 ms·
> relying on static initialization is something one should think about potentially solving differently This is such a notorious problem, it even has a name: St
by pdpi 9y ago
> relying on static initialization is something one should think about potentially solving differently
This is such a notorious problem, it even has a name: Static Initialisation Order Fiasco (see: https://isocpp.org/wiki/faq/ctors#static-init-order https://isocpp.org/wiki/faq/ctors#static-init-order)
The symmetrical Static Destruction Order Fiasco is also a very fun problem to deal with. The solution proposed for SIOF in the C++ FAQ does nothing to help you deal with this one, though.
- pcwalton 9y agoPerhaps worse, lots of new languages, for example Go, copied this mistake from C++. :(
- helper 9y agoIs the "static initialization order fiasco" a thing that can happen in go? The order of package level variable initialization is well defined in the spec and because go doesn't allow import cycles it seems like the issue mentioned in the linked page is not possible.
- pcwalton 9y agoStatic initialization order may be defined, but that doesn't mean it's easy to reason about.
- pjmlp 9y agoActually, if you mean package initialization blocks, they were already present in Mesa derived languages.