• 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
Forcing ulong AE constants
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Forcing ulong AE constants


  • Subject: Forcing ulong AE constants
  • From: Steve Mills <email@hidden>
  • Date: Thu, 15 Jul 2010 11:20:21 -0500

Recently, something changed (I'm not sure what) that made our AE enums come out as signed longs instead of unsigned longs. I thought it might've been when I changed one 4-char code to its hex equivalent, but changing it back didn't fix the problem. Now we have tons of warnings about comparisons always being true or false because it thinks it's comparing an unsigned to a signed. Is there any way to force enums to be unsigned long? Declaring one of them as something like 0x12345678UL didn't work.

I was going to convert them all to consts instead of enums, but then they wouldn't work in our .r files. So I came up with this scheme that would allow the constants to be one of three types, depending on the type of file being compiled:

#if ae_constants_type == ae_constants_are_enums
	#define ae_eq(sym,val) sym = val,
	#define ae_begin enum {
	#define ae_end };
#elif ae_constants_type == ae_constants_are_consts
	#define ae_eq(sym,val) const DescType sym = val;
	#define ae_begin
	#define ae_end
#elif ae_constants_type == ae_constants_are_defines
	#define ae_eq(sym,val) #define sym val
	#define ae_begin
	#define ae_end
#endif

ae_begin
ae_eq(enumNone, 'None')
ae_eq(kAEInteract, 'Inta')
ae_eq(kBaseClass, 'Base')
etc.
ae_end

But that didn't work when compiling the Terminology.r file (ae_constants_type is set to ae_constants_are_enums in this case):

/depot/cmyk/creatortech/portablecrossproject/DogbertAEConstants.h:53:0 Expected identifier, but got '('

So it didn't know it should expand the ae_eq macro I guess. I also don't know if the 3rd type will work, when the macro #defines another #define, because I don't know if the preprocessor will do it more than once.

Any brilliant ideas?

Steve Mills
Drummer, Mac geek



 _______________________________________________
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

  • Prev by Date: Cusom codesign resource rules getting copied into app. Why?
  • Next by Date: UIAutomation vs. "Automation
  • Previous by thread: Re: Custom codesign resource rules getting copied into app. Why?
  • Next by thread: UIAutomation vs. "Automation
  • Index(es):
    • Date
    • Thread