Re: #define bug in gcc for delta builds?
Re: #define bug in gcc for delta builds?
- Subject: Re: #define bug in gcc for delta builds?
- From: Matt Gough <email@hidden>
- Date: Wed, 4 Feb 2009 13:47:39 +0100
On 4 Feb 2009, at 13:12, Stephen Northcott wrote:
What was happening, and I spotted this stepping through in XCode was
that when the instance of the class was first created it was being
created one way. Immediately after creating it I called a member
function of that instance and once inside the member function it was
working with the opposite definition.
One case has a block of data 40 bytes long, and the other had a
block 44 bytes long.
Looking at the same instance of that class I could go up and down a
level in the debugger and see the address of everything shift back
and forth by 4 bytes!!
Ahh, Now I see (as I recently fixed a similar issue here)
What I think you have is this:
class Foo
{
Foo();
void SomeMethods();
....
private:
int mVar1;
#ifdef BAD_Whatever
int mVar2;
#endif
int mVar3;
};
In Foo.cpp you define BAD_Whatever so as far as any code in their is
concerned your class has 12 bytes of member variables.
But in bar.cpp, where you don't define BAD_Whatever, you do something
like this:
Foo* newFoo = new Foo;
At this point, the compiler thinks that it only needs to allocate 8
bytes for the Foo (as that is how large the class is as seen in
bar.cpp) so you object ends up being smaller than the Foo class thinks
it is. Any attempt to access mVar3 inside foo's code will result in it
writing to un-alloced memory.
In a nutshell, when you do new (or allocate an object on the stack),
the class itself is NOT responsible for ensuring the correct omount of
memory is reserved, it is the compiler that does.
(If you were to allocate any Foos within Foo.cpp itself then they
would be the 'correct' size.
Matt
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden