Misaligned elephants
-
If have a class containing this snippet declared in a C++ header file.
protected: \_tChar\* m\_p; //-------------------------------------------------------------------------------- struct sHeader { unsigned short usAlloc; unsigned short usLen; }; //-------------------------------------------------------------------------------- struct sFooter { unsigned short usRefCount; }; //-------------------------------------------------------------------------------- virtual unsigned short HeaderByteSize( void ) const { return sizeof( sHeader ); }The header is used by half a dozen Dlls which are all part of a project. Instances of the class are created and passed around freely except it doesn't work. Because one dll has decided that
sizeof( sHeader )is 4 bytes as expected and another has decided that it's 16. The same header file, same build options and everything built together in a clean build. :mad::mad: The whole point of usingsizeof( sHeader )in the first place instead of just 4 was so that alignment wouldn't screw thing up. :mad::mad::mad: Now what do I do?"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
To guard against issues like that where the size of objects REALLY mattered, I've always used a
static_assert[^] to express static constraints like that:protected:
\_tChar\* m\_p; //-------------------------------------------------------------------------------- struct sHeader { unsigned short usAlloc; unsigned short usLen; }; static\_assert(sizeof(sHeader) == 4, "sHeader is an unexpected size!"); //-------------------------------------------------------------------------------- struct sFooter { unsigned short usRefCount; }; //-------------------------------------------------------------------------------- virtual unsigned short HeaderByteSize( void ) const { return sizeof( sHeader ); }Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p CodeProject MVP for 2010 - who'd'a thunk it!
-
To guard against issues like that where the size of objects REALLY mattered, I've always used a
static_assert[^] to express static constraints like that:protected:
\_tChar\* m\_p; //-------------------------------------------------------------------------------- struct sHeader { unsigned short usAlloc; unsigned short usLen; }; static\_assert(sizeof(sHeader) == 4, "sHeader is an unexpected size!"); //-------------------------------------------------------------------------------- struct sFooter { unsigned short usRefCount; }; //-------------------------------------------------------------------------------- virtual unsigned short HeaderByteSize( void ) const { return sizeof( sHeader ); }Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p CodeProject MVP for 2010 - who'd'a thunk it!
A good point, thanks. I have a
static_assertand I should be using it."The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
I've not used SharpDX, but my understanding is that a very thin wrapper around DirectX, so probably diving in the DirectX documentation can help you (actually DirectX documentation is full of examples that, hopefully, could be easily translated into C# or used directly in most cases).
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
the toolkit is a high level abstraction like XNA, the wrapper part is actually well documented with references to the unmanaged documentation and descriptions of the small differences.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p) "Given the chance I'd rather work smart than work hard." - PHS241 "'Sophisticated platform' typically means 'I have no idea how it works.'"
-
YvesDaoust wrote:
Could it be a struct member alignment option silently set in a preceding header file
I suspect it might be just that, but leaking from a Windows header. Including pulls in which in this case is a project header not a system header. My guess is that the string support code is being included in the middle of a windows header section that for some reason has different alignment options. Tracking it down or doing anything about it would be rather difficult though. I've worked round this one but I'll be on the lookout next time and also need to get pragma pack support into my Compiler support library as soon as I can.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Yes, it also occurs to me that your core problem is not the size but the inconsistency. I would look for a platform specific solution to this problem rather than trying to find a platform generic packing instruction. Good luck anyway.
-
If have a class containing this snippet declared in a C++ header file.
protected: \_tChar\* m\_p; //-------------------------------------------------------------------------------- struct sHeader { unsigned short usAlloc; unsigned short usLen; }; //-------------------------------------------------------------------------------- struct sFooter { unsigned short usRefCount; }; //-------------------------------------------------------------------------------- virtual unsigned short HeaderByteSize( void ) const { return sizeof( sHeader ); }The header is used by half a dozen Dlls which are all part of a project. Instances of the class are created and passed around freely except it doesn't work. Because one dll has decided that
sizeof( sHeader )is 4 bytes as expected and another has decided that it's 16. The same header file, same build options and everything built together in a clean build. :mad::mad: The whole point of usingsizeof( sHeader )in the first place instead of just 4 was so that alignment wouldn't screw thing up. :mad::mad::mad: Now what do I do?"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
Now what do I do?
I would start by figuring out what in fact is different in that build. Might also help to investigate what is actually driving the size difference. Presumably packing, or lack thereof, however there is another option.
-
Yes, it also occurs to me that your core problem is not the size but the inconsistency. I would look for a platform specific solution to this problem rather than trying to find a platform generic packing instruction. Good luck anyway.
Is this on a 16-bit, 32-bit or 64 bit environment? If you are using Visual Studio, check the preprocessor directives in all the projects. Also check the code generation struct member alignment. I've had this before: all projects just used default settings except some were VS6, some were VS2003 and some were VS2005. I just got random unexplanable crashes, so, like you, I decided to look at the sizeof things and they were very different. Nowadays I avoid such things by not having inline functions. It may run slower but at least you don't spend weeks trying to figure out stuff like this.