Re: compiler bug??
Re: compiler bug??
- Subject: Re: compiler bug??
- From: Andreas Grosam <email@hidden>
- Date: Fri, 9 Sep 2005 02:06:25 +0200
On 08.09.2005, at 15:21, Philip Lukidis wrote:
I'm pretty new to kext development. Recently, I've encountered
something
very strange in one of my classes. Briefly, when I place a member
variable
in a certain position within my class, all hell breaks loose. The
member
variable is placed within an #ifdef #endif block, and the symbol is
defined
with the -D switch. When I removed the #ifdef #endif block, I had no
problems. When I moved the entire #ifdef #endif block to another
location
within the class, I had no problems. But when I placed the #ifdef
#endif
block right under the public keyword, all hell broke loose.
Frankly, you coudn't do something more dangerous!
Having a class, which class layout is significant, having a member
variable in a class definition which is in a public header file and
which is surrounded by a conditional macro which is specified in the
command line -- outch!!
double outch!!
I suggest using a config header which defines the macro. This header
must be included in the header where the class is defined. This does
not automatically eleminate all subtle cases where someone changes the
config and does not recompile all dependent projects - but at least it
helps to remove the error prone definition of the macro in the command
line - or build settings.
And don't forget to comment the macro in the config file - and mention
also that if changing it, "all hell breaks loose!".
Regards
Andreas
Changing the optimization level to -O0 had no effect. What are your
thoughts on this? Is there some sort of fatal overflow into my class
memory, something else, or is this a compiler bug? Note the following:
#ifdef FIRELOGCORE
myClass* mPub;
#else
void* mPub
#endif
worked, while
#ifdef FIRELOGCORE
myClass* mPub;
#endif
did NOT work when placed under the public keyword. Your thoughts on
the
subject would be appreciated.
thanks,
Philip Lukidis
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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