• 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 03:57:55 -0800


On Feb 4, 2009, at 3:44 AM, Stephen Northcott wrote:

Not getting any errors. So I am little confused by that. There is no namespace issue here either AFAIK.
Are we getting crossed lines here. Its the #define that is in effect redefined (if anything), not an actual variable.

Now I am confused. Your example showed global variables declared in the header. That's usually a bad idea since you end up with multiple copies of them and you get link errors like I showed in the response to Matt Gough. Are you saying that instead of variables being guarded by the #ifdef, you have other #defines or do you think that _FOO_ (or whatever you said you're actually using) is being redefined at some point? It sounded like you meant variables before and preprocessor #defines here.


My guess was that in a.cpp you were defining _FOO_ and #including the header while in b.cpp you were not defining _FOO_ and then #including the header.

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.

Like I said the #define is in foo.h and only ever used in foo.cpp and foo.h. foo.cpp includes foo.h. And any where else that the class in foo is used I also include the same foo.h


So foo.h looks something like

#define _FOO_ // enable feature foo
//...
#ifdef _FOO_
//...
#else
//...
#endif

And in foo.cpp you use _FOO_ similarly _after_ #including foo.h?

If so, that rules out what I said above about a.cpp and b.cpp.

--
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>
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>)

  • Prev by Date: Re: #define bug in gcc for delta builds?
  • 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