🚀 go-pugleaf

Mike ODowd wrote:
#-> I have noticed that the size of my code has been growing
#-> at an alarming rate recently. After some investigation, I
#-> discovered that it is due to multiple copies of virtual tables.
#-> 
#-> It seems that each object file that accesses a class, ends up
#-> with a copy of that class' virtual table. I one case, I counted 
#-> 91 object files that contain a copy of the same virtual table.
#-> 
#-> The virtual tables are taking up something like 25% of my code.
#-> 
#-> Please tell me that there is a way around this, that my code size
#-> is not going to expand exponentially.
#-> 
#-> I am using gcc v2.6.0.

I may know what's up:  If you define instances of your class in the 
header file:

<foo.h>

Myclass Foo1;

Every file that includes foo.h will make a copy of Foo1, and a virtual 
table to match.  Make sure all data declared in the header files is 
"extern".  Then define the actual instance in one of your modules.

{ This isn't a clear example - anyone care to summise the problems of
  inlines/templates and vtbl emmision ?? -mod}

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

In article <4g1pqs$pvl@netlab.cs.rpi.edu>, overhaul@nmia.com (Daniel N.
Sands) writes:
|> Mike ODowd wrote:
|> #-> I have noticed that the size of my code has been growing
|> #-> at an alarming rate recently. After some investigation, I
|> #-> discovered that it is due to multiple copies of virtual tables.
|> #-> 
|> #-> It seems that each object file that accesses a class, ends up
|> #-> with a copy of that class' virtual table. I one case, I counted 
|> #-> 91 object files that contain a copy of the same virtual table.
|> #-> 
|> #-> The virtual tables are taking up something like 25% of my code.
|> #-> 
|> #-> Please tell me that there is a way around this, that my code size
|> #-> is not going to expand exponentially.
|> #-> 
|> #-> I am using gcc v2.6.0.
|> 
|> I may know what's up:  If you define instances of your class in the 
|> header file:
|> 
|> <foo.h>
|> 
|> Myclass Foo1;
|> 
|> Every file that includes foo.h will make a copy of Foo1, and a virtual 
|> table to match.  Make sure all data declared in the header files is 
|> "extern".  Then define the actual instance in one of your modules.
|> 
|> { This isn't a clear example - anyone care to summise the problems of
|>   inlines/templates and vtbl emmision ?? -mod}
|> 
|>       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
|>       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
|>       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
|>       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

I observed the same thing with Sparcworks (3.0.1 or 4.0.1?)
Many compilers have the following option which will save you space.

     +e[01]    Only to be used on classes for which virtual functions are
               present, and all the virtual functions are either defined as
               inline or pure.  In this circumstance, this option optimizes
               a program to use less space by ensuring that only one
               virtual table per class is generated.  +e1 causes virtual
               tables to be external and defined.  +e0 causes virtual
               tables to be external but only declared.  This option is
               ignored for any class that contains an out-of-line virtual
               function.

Although the above description (from our Pyramid compiler) claims
that this only applies to classes with no non-inline functions
(and thus no implementation object file), I believe it applies
to all classes with Sparcworks.  It is a useful feature if you need
to put objects with virtual functions in shared memory.

- Bob
-- 
Robert Lister

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]