Re: [Valgrind-users] Uninitialized access findings on non-static file scope variables that's been initialized?

[David C. <dcc...@ac...>]

On 8/12/2015 10:18 PM, Jeffrey Walton wrote:
> On Wed, Aug 12, 2015 at 6:02 PM, David Chapman <dcc...@ac...> wrote:
>> On 8/12/2015 1:09 PM, Dan Kegel wrote:
>>> ...
>> So even though I just told you how to guarantee that global variables in C++
>> are initialized before they are used, don't do it. :-)  Refactoring sounds
>> expensive but in the long run it is cheaper than debugging interactions
>> between global variables.
> Thanks David.
>
> 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.  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."  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.

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).  Resolving initialization order dependencies 
would have been a nightmare.  I don't think initialization order was a 
problem in that particular package, but "hey - who changed that 
variable???" was a big deal.  The code could take hours to run, so 
debugging could be very slow and tedious.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com