>> 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). > Also, you can get dependency loops very quickly: "object 1 depends > on object 2, object 2 depends on object 3, object 3 depends on object 1." Agreed. Directed graphs without loops is my problem, not the language's or compiler's problem. Its no different than header loops. > That's basically what happened to me, and I had to rewrite an awful lot of > code to get rid of it. If the dependency loop goes through an outside > library, or worse yet appears just by linking a set of outside libraries, > you're stuck. This is where the hand waiving comes in with "provide a way for me to express A depends on B". Sometimes I need to say, "Within my library, Object A depends on Object B". And other times I need to say "My library depends on libstdc++ (GNU runtime) or libc++ (LLVM runtime)". I think both represent real world use cases (q.v.), and both are reasonable. My list would also include a way to express "My Object A depends upon Library X". That use case covers users of non-standard libraries. I think it represents a real world use case, and its reasonable, too. > The software package that I mentioned had hundreds of global variables (I > didn't have the nerve to count them all, but the company founder thought > they were a great way to avoid the overhead of passing parameters to > functions). Oh man, my heart goes out to you. (I'm not throwing stones. Fresh out of college, I used to do that too. I'm kind of lazy, and I still do it for my POCs). Jeff ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
