On 8/13/2015 10:28 AM, Jeffrey Walton wrote:
> On Thu, Aug 13, 2015 at 12:06 PM, Dan Kegel <d...@kegel.com> wrote:
>> On Thu, Aug 13, 2015 at 6:11 AM, Jeffrey Walton <noloa...@gmail.com> wrote:
>>> Al we have managed to do since C++98 (maybe earlier) is move the
>>> problem around because the C++ language has not given us the tools we
>>> need to address the problem.
>> What part of "stop doing that" does C++ get in the way of?
> The objects simply exist, and telling someone "don't do that" is
> wishful thinking at best. That's the implicit bikeshedding I was
> talking about.
>
> And converting the file-scoped globals into locals with accessors
> suffers the same problem on the destructor side. So the problem was
> not fixed; rather it was just moved around.
>
"Bikeshedding" is not the analogy I would apply; it's more like "camel's
nose in the tent". The problem sounds tractable as long as it is kept
small, but people will naturally want more and more. Even the GCC
init_priority extension is limited to 65435 (65535 - 101 + 1) priority
levels. What if someone has thousands of global variables to order
(e.g. an embedded system with no memory allocator)? What if the
libraries don't play nice and all of them ask for priority 101? What if
priorities 101 to 10000 are all taken, and one more variable needs to be
added in the middle?
My code "simply existed" and it had initialization order problems. I
rewrote it. That cost money, but I have never regretted it.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
