[cfe-dev] better way to test for explicit C++ constructor?

Peeter Joot peeter.joot at gmail.com
Tue Dec 11 16:08:38 PST 2012


>
> I'm rather confused by this whole thread; for the given analysis, I
> don't see how any constructor other than the one actually used to
> construct the global in question matters.
>
>
The problem I was trying to solve is illustrated by:

struct nowHasConstructor
{
   int x ;

   withConstructor() : x(3) {} // Constructor added to solve uninitialized
variable problem with uses of this type on the stack.
} ;

struct b
{
   nowHasConstructor d ;
} ;

struct a
{
   b c ;
} ;

struct bigDisgustingStructureContainingWayTooManyOfTheTypesInOurProduct
{
   // ... lots of stuff

   struct a ;

   // ... lots more stuff
} ;

bigDisgustingStructureContainingWayTooManyOfTheTypesInOurProduct
theBigGiantGlobalVariable ;

I'd added the constructor for good reasons and it should solve the usage
problems we have with this type in some cases.  However, the type in
question also ends up indirectly included in the big ugly global.

That big ugly global can't have global constructors due to an AIX issue: a
pure-C linked app won't invoke global constructors from a C++ shared lib
unless it is dynamically loaded.  For this reason we forbid global
 constructors in our "application" library, at least on AIX.  On that
platform, we explicitly fail our link of this library if we find a linker
reference to such a constructor (deleting the library in the make rule).

This question was motivated by me trying to track down what made
theBigGiantGlobalVariable now require construction (I knew what change
triggered this but not exactly where it caused the trouble).  I found it
three levels deep in a couple of places (not obvious by inspection, but my
AST visitor  was able to help me find it, since I was able to dump all the
direct and indirect dependencies of the bigDisguistingType).

-- 
Peeter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121211/40e7d524/attachment.html>


More information about the cfe-dev mailing list