grunwald@FOOBAR.COLORADO.EDU (Dirk Grunwald) (10/18/89)
If you define an overloaded new, you're passed the size of the structure you are to allocate. In the latest g++.xtar.Z, this differs from the value returned via ``sizeof'' for that class. Is this intentional? For example, in one class I have, operator new is passed a size of 183 while sizeof returns 176. Does the sizeof() operator omit space for vtable pointers? Why 7 bytes different? Is this a bug or a feature? Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
tiemann@LURCH.STANFORD.EDU (Michael Tiemann) (10/18/89)
Date: Tue, 17 Oct 89 12:41:35 -0600 From: grunwald@foobar.colorado.edu (Dirk Grunwald) Reply-To: grunwald@foobar.colorado.edu Office: 6-1 EECR (303) 492-0452 If you define an overloaded new, you're passed the size of the structure you are to allocate. In the latest g++.xtar.Z, this differs from the value returned via ``sizeof'' for that class. Is this intentional? For example, in one class I have, operator new is passed a size of 183 while sizeof returns 176. Does the sizeof() operator omit space for vtable pointers? Why 7 bytes different? Is this a bug or a feature? Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) Your class has an object which requires 8 byte alignment. Since malloc does not, a priori, give you reasonably aligned memory, I make the compiler ask for enough that it can cause that memory to be appropriately aligned. The way I implement this assumes a minimum alignment from malloc. Conservatively this would be 1 byte, but it would be inefficient to force alignment of every call to malloc, so I assume malloc returns chunks which are aligned enough for a pointer. In most cases, this is four bytes. Michael
andrew@frip.WV.TEK.COM (Andrew Klossner) (10/19/89)
Michael writes:
"Since malloc does not, a priori, give you reasonably aligned
memory ..."
On what system does malloc misbehave in this way? The BSD, system V,
and SunOS man pages all state that malloc *does* give correctly aligned
memory, and I haven't yet encountered an implementation for which this
is untrue. (Maybe you have a non-Unix system in mind?)
-=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]