This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: empty member optimization?



> In answer to something Jason posted a couple of weeks ago...
> 
> I don't know of anything in the Draft that forbids eliding
> storage of empty member objects that are followed by an
> access specifier, or at the end of the object:

I think we settled this argument (or, if I remember right, Jason did).  We
can eliminate storage for empty objects *except* in the cases where two
empty objects of the same class wind up next to each other.  In all other
cases the storage can be eliminated.  It's the same for members or bases.

I don't think it's that complicated to program: when generating the
class layout, you normally assign 0 bytes for empty objects.  But
if the last object is empty, you keep track of its class.  If an
empty object is then added, you see if it is of the same class as
an empty object at the end.  (Don't forget to handle empty derived
classes of empty base classes).

Padding is added if and only if two empty objects that are of (or are
derived from) the same class wind up next to each other.  I think that
adding one byte of padding is fine in all cases: the pointers to the two
distinct empty objects might be compared (and must not compare equal), but
they will not be dereferenced, so alignment does not matter.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]