• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: #define bug in gcc for delta builds?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: #define bug in gcc for delta builds?


  • Subject: Re: #define bug in gcc for delta builds?
  • From: Steve Checkoway <email@hidden>
  • Date: Wed, 4 Feb 2009 04:33:54 -0800


On Feb 4, 2009, at 4:12 AM, Stephen Northcott wrote:

I have some variables in the class definition (in the header file) and some code in the .cpp file being conditionally compiled based on a set of #ifdef ... #else ... #endif statements.

Okay, that was my first guess, "especially if what you are conditionally defining is part of a struct or class definition." You responded that it was outside the class definition though. That's what's been confusing me. That and the bit about global variables. It sounds like these aren't global variables at all.


The #define for those conditions is defined in the header file. The #define is simply #define DO_BAD_STUFF

And the #ifdef is simply #ifdef DO_BAD_STUFF etc.

To 'undefine' it I simply comment the #define out in the header file so it is never defined.

Okay, I understand now.

You mentioned data offsets before but said that it was outside the structure definition. I'm curious how you're determining the offsets of the variables.

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.

My guess now is that Xcode isn't doing dependency tracking for for that header. For example:
foo.h contains the declaration of class foo
foo.cpp contains the implementation of class foo
user.cpp #includes foo.h and uses class foo.


The incremental compile compiles user.cpp and foo.cpp. Then you change comment out the _FOO_ define which causes Xcode to mark foo.cpp as dirty but not user.cpp so when it gets recompiled, they have different ideas about the size of foo.

Is the header file included in the Xcode project? I don't know if it has to be included in the particular target or not, but I seem to recall that it doesn't.

--
Steve Checkoway

    "Anyone who says that the solution is to educate the users
    hasn't ever met an actual user." -- Bruce Schneier




Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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

  • Follow-Ups:
    • Re: #define bug in gcc for delta builds?
      • From: Stephen Northcott <email@hidden>
    • Re: #define bug in gcc for delta builds?
      • From: Ken Thomases <email@hidden>
References: 
 >#define bug in gcc for delta builds? (From: Stephen Northcott <email@hidden>)
 >Re: #define bug in gcc for delta builds? (From: Steve Checkoway <email@hidden>)
 >Re: #define bug in gcc for delta builds? (From: Stephen Northcott <email@hidden>)
 >Re: #define bug in gcc for delta builds? (From: Steve Checkoway <email@hidden>)
 >Re: #define bug in gcc for delta builds? (From: Stephen Northcott <email@hidden>)
 >Re: #define bug in gcc for delta builds? (From: Steve Checkoway <email@hidden>)
 >Re: #define bug in gcc for delta builds? (From: Stephen Northcott <email@hidden>)

  • Prev by Date: How to define a preprocessor macro.
  • Next by Date: Re: #define bug in gcc for delta builds?
  • Previous by thread: Re: #define bug in gcc for delta builds?
  • Next by thread: Re: #define bug in gcc for delta builds?
  • Index(es):
    • Date
    • Thread