i have a quite strange problem. my class has -among others- following memers:
GLboolean has_alpha;
GLuint width;
GLuint height;
GLuint length;
GLuint millisPerF开发者_开发问答rame;
GLfloat uv[2];
GLuint texsize[2];
GLint compsize;
// location2
long preload_interval_next;
long preload_interval;
if i put the has_alpha at (location2) i get
a) different object size, sizeof reports 248 instead of 252 bytes
and
b) hefty heap corruptions
GLboolean is defined as unsigned char, but since i use NO optimization at all ( double checked this ) this should be padded to 4 bytes anyway. And in the end, if it pads, it should do it at both locations ..
compilers tested: CLANG ( c++ ), GCC4.2 com.apple.compilers.llvmgcc42
Anyone an idea how to track this down?
The problem here is almost certainly not in the members you have listed, but another one, possibly an int
, pointer or bool
that is not properly initialised in the constructor. Please post a larger example that fails, and make sure you initialise all members using the constructor initialisation list.
I highly doubt the problem is in the code you posted. You'd need to show us the rest of the class. However some hints:
a) may happen due to alignment (no, it shouldn't do it at both places the same, read about data alignment)
b) may happen if you pass a pointer of this structure to some GL calls that expect some kind of ordered alignment
If you want to find out where the padding occurs, you can use the -Wpadding option of gcc, or try out pahole, which can be used to optimize the structure size: https://twiki.cern.ch/twiki/bin/view/Atlas/UsingPahole
If it's at the beginning it HAS to pad to have the other variables on the right alignment. If it's at the end it doesn't have to pad and it might be able to disappear into the already padded size. No mystery there.
Heap corruption is nothing to do with this, it's just being exposed by having different allocations due to the new size - that is, random chance.
精彩评论