Quote:Original post by Dmytry
three words: initialization order problems. The thing that singleton is intended to solve.
With local static, it is created when execution goes over it.
I'm not sure I understand how this solves initialization order problems, specifically since the objects are created as execution hits them. That means that your objects are created invisibly depending on the first use of the functions your macro creates.
For example, let's take two modules 'Foo' and 'Bar' that are created using your macros. If Bar HAS to be instantiated before Foo (to illustrate the problem), how would you keep track of that? Someone may unknowingly call the Foo function before Bar, creating the Foo before Bar and causing havoc. The initialization order problem is still there, but your solution (imo) makes it harder to track down which objects are created when and where
since it's dependant upon execution.
Singletons or not, I'm a BIG fan of very explicit Create-Destroy / Init-Deinit construction pairs. That way I know exactly which objects / systems are created in what order, and conversely I know exactly which order they are destroyed.
Also, destruction orders are VERY important, and should never be ignored if it matters. And the worst part is, they're sometimes the hardest ones to track down / solve.
