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: Andreas Grosam <email@hidden>
- Date: Wed, 4 Feb 2009 11:57:58 +0100
Hi Stephen,
honestly, I suspect there is something wrong with your code. It seems
you are not 100% familiar with the C++ concepts.
On Feb 4, 2009, at 9:42 AM, Stephen Northcott wrote:
I have been using #define _FOO_ to conditionally alter the
compilation of parts of a class.
In the .h file I had something like this..
#ifdef _FOO_
int A = 2;
#else
int A = 2;
int B = -1;
#endif // _FOO_
Well, this code is quite unusual - maybe for testing purposes only. A
side note: basically, do not use names for macros that begin with an
underscore.
So, it should also be clear, what this code means: here you define
variables in global namespace - aka "globals" with external linkage.
This means, you can access these objects from any other translation
unit. These are the "infamous" globals.
In the related .cpp file I would use the same value _FOO_ to control
how code behaved with regards accessing A, or A and B.
If we assume that _FOO_ is not defined then...
When stepping through in XCode
I'm assuming you are stepping through *your* code using Xcode's
debugger ...
I noticed that when the class instance is created
to be precise, you only create instances of a certain class, not
"class instances".
it will be created according to _FOO_ being defined, when it is
actually not defined as I stated just above.
that's confusing me. How do you test whether _FOO_ is defined or not.
If you are unsure, just insert a
#error blah
directive in your .cpp file and compile it.
Where is _FOO_ actually defined anyway, and how?
However, stepping into a member function the code would act
correctly addressing data as if _FOO_ was not defined.
Is this the same translation unit as where you created the class, or
another one?
If this is another one, _FOO_ might be defined differently.
Obviously this causes a lot of problems. Data is offset, and it
makes no sense to me, and threads / the main program crash!
Well, sure :)
Ah, and your program crashes! (I thought it was Xcode that crashed ...)
A clean all will resolve this and things will behave again.
If a program behaves as expected, that doesn't mean that it is
correct ...
This is happening several times a day with incremental builds, and
had been intermittently troubling me for some time now, without me
actually knowing what was going on.
It certainly seems like a bug to me. But I am also concerned that
perhaps some corruption has crept into my project..
It's probably not the project, I suspect it is your code. You should
have a header file where you define (or omit the definition) of all
the macros that effect your code. Then include this header in every
translation unit.
Any advice / comments greatly appreciated.
Please try to be more precise when describing problems. I'm having
trouble to understand what's actually the issue.
Regards
Andreas
_______________________________________________
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