On Thursday, August 13, 2015 07:29:22 AM Jeffrey Walton wrote: > >> Just venting here, but... > >> > >> $ ls *.h *.cpp | wc -l > >> 269 > >> $ grep class *.h *.cpp | wc -l > >> 1332 > >> > >> Of 1300+ classes and nearly 270 source files, there are 5 globals that > >> are sensitive to their initialization order. 3 are std::strings and 2 > >> are C++ objects. > >> > >> Its *really* pathetic the C++ language lacks a mechanism for me to say > >> "Object 1 depends upon String 1, 2, 3", and "Object 2 depends upon > >> Object 1 and String 1, 2, 3". > >> > >> It's not like I'm asking the compiler to solve some NP-hard problem. > >> It does not have to solve any problem. The language just needs the > >> give me the ability to express a relative ordering among a handful of > >> objects. > > > > You might have only five variables, but the next person will have a few > > more, and the next will have still more... I doubt that any standards > > committee would provide a solution that would work only for a small set > > like that. > > Yeah, but that's just bikeshedding, no? (http://bikeshed.com/). > > Static variables simply exist, and the C++ committee will not be able > to wish them away. Any GNU mirror (like ftp://gnu.mirror.iweb.com/) or > code repository (like GitHub or Google Code) will demonstrate it in > practice. > > As long as the language provides a way for me to express A depends on > B, then the language's job is done (some hand waiving). If the > committee claims I should not be able to do that, then that's an > explicit bikeshed moment. Or if they don't give it to me, then that an > implicit bikeshed moment. > > Or if the committee claims I should do X (like X = Singleton with a > smart pointer and dynamic allocation), then that's a bikeshed moment, > too. (I personally despise the memory manager, and the run time costs > associated with going to the memory manager. That's why I prefer > fixed, static allocations).
Just a side note:
Static globals in C++ are OK as long as they have a trivial constructor. As
soon as you do anything fancy and code needs to run upon initialization, then
you pay dearly due to the static initialization order fiasco - but also this
significantly increases startup time of your application, as *everything* will
be initialized before main is run. Because of this alone, many C++ libraries
like Qt right-out reject any code that adds global statics with non-trivial
constructors.
So if you are saying you care about the runtime cost of using a memory
manager, then you should re-think whether you really want to keep using global
statics. Most notably, look at the code that is created for static
initialization: Often, you'll incur several cache misses during static
initialization as code from all over needs to be paged in.
My suggestions is to stop using static globals altogether - and that does
_not_ mean you have to use heap allocated objects!
Foo& foo()
{
static Foo foo;
return foo;
}
This will be constructed on first use, is thread safe, and you can
specifically define the construction order by calling foo somewhere in your
code.
Bye
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
