Hi Stephen - glad to hear everthing now working.
In response to your specific request for more info, (my apologies for
wandering off the OSG track)
QUOTE
The declaration of the class variable in my main loop which allows the
window class to exist, and the window name crash bug, seem very strange, and
I would love if you had any more info on your comments, Philip. So that I
may try to wrap my head around that and solve it. I have not actually
checked if this problem has gone away in my new Visual Studio setup, but
will today.
> This sounds like a simple byte alignment problem - the same header
> file is included by two different files but each file has a
> different packing pragma.
UNQUOTE
consider the following:
Header.h
========
struct Fred
{
char Byte1;
short Byte2;
int Byte4;
};
File1.h
=======
#pragma pack(1)
#include "Header.h"
struct MyFred1
{
Fred m_Fred;
void operator=( const Fred*);
};
File2.h
=======
#pragma pack(4)
#include "Header.h"
struct MyFred2
{
Fred m_Fred;
void operator=( const Fred*);
};
Main.cpp
========
#include "File1.h"
#include "File2.h"
int main()
{
MyFred1 dst;
MyFred2 src;
dst.m_Fred = src.m_Fred; // Will be uppredictable
return 0;
}
These are very simple example files but prove the point.
The assigment in main() will compile just fine but may crash the program at
runtime because the space occupied by the lhs is smaller that the rhs, even
though both use the same struct definition. The reason is that
MyFred1::m_Fred has no packing bytes between struct data members whilst
MyFred2::m_Fred is four byte aligned ie extra padding bytes exist in the
MyFred2 version.
In a similar vein, the "new" operator differs in the way it organises memory
between different build types. If one DLL creates performs a "new" on
multithreaded DLL which then gets deleted by another DLL built with static
linking, then the delete operators for the two DLLs will may different
assumptions about memory layout. The only way to circumvent this is enforce
the rule that ALL DLLS must be built the same way, or to use the same DLL to
create (new) and erase (delete) dynamic memory.
Note that in all cases, the build will probably work just fine because the
program is syntactically correct, but will mysteriously crash at the first
mismatch.
PS: It took me sometime to figure out why I never suffered problems
transferring data from memory to disk and back - and then I remembered - I
serialise the data which hides all these issues. Older code that wrote and
read structures would have a real hard time.
PPS This is another reason to not try mixing VS 7 and VS 8 DLLs (lots has
been written on this subject) especially the System::String
re-implementation.
Hope the odd few words above are useful - apologies for wandering of the OSG
beaten track though.
Philt
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
