On Jun 17, 2005, at 10:28 AM, Nick Nallick wrote:
On Jun 16, 2005, at 6:19 PM, Chris Espinosa wrote:
1) I added a header search path to the project but it had no effect. When I examined the arguments passed to the compiler this path wasn't being passed to the compiler. I had to add the path to the target for it to work. What is purpose of this setting in the project?
You set it in the project if you want it inherited unchanged by all targets, or augmented in a target that uses $(value) to refer to the project-level setting.
On Jun 16, 2005, at 3:33 PM, Scott Tooker wrote:
Double-check that you didn't have an empty setting at the target level, since that would have masked the project level setting.
Thanks for the explanation but I'm confused. I set a value in the project and left the target value blank because I wanted the same value used by all targets. But apparently leaving the target value blank caused a blank value to be used in the target. How do I tell a target to use the project value?
If the setting is bold in the target inspector, it's overriding the project level. Even if it's blank (it's sometimes useful to say "No, I don't want to inherit these values.). To stop the override and let the project values "shine through," select the setting in the target inspector and delete it; the boldface will be removed and you'll see the project-level settings. 3) Frequently when I'm editing a file, I'll hit cmd-K to compile that one file and check for errors. When I compile a single file with the "Compile" menu command the compiler will frequently miss errors and report "Build succeeded". When I use the build command to compile the file the errors will be reported. What am I doing wrong?
This is a known bug if your sources are "up and over" from your Xcode project file. We're working on it.
FWIW, I have the same problem in some circumstances when using a file that's in a folder that's a peer of the project file (at least with Rez).
Single-file compile isn't thoroughly implemented for files other than source code files
5) Is there any way to turn the objective-c compiler on and off within in a C++ file (e.g., #pragma objective_c on)?
No, compiler semantics are on a per-file granularity.
6) How do I tell if the objective-c compiler is active (e.g., #if __option(objective_c))?
For C++ you can do #ifdef __cplusplus. Is there no equivalent for Obj-C?
Ah, yes there is: if you compile a .m or .mm file, you get #define __OBJC__ 1
predefined by the compiler.
8) Is there a more legitimate way to dereference and increment a pointer by a size other than it's native size than what I'm doing in the following?
UInt8* ptr = something; UInt32 value = *((UInt32*) ptr)++;
warning: target of assignment not really an lvalue; this will be a hard error in the future
gcc is kicking about the *( )++. You can't increment a dereference, because the address of the dereference is a register, and you can't take the address of a register.
ptr = (UInt8*) ((UInt32*) ptr + 1); UInt32 value = *((UInt32*) ptr);
Perhaps I'm being obtuse but this doesn't make sense to me. I'm incrementing the pointer, not the dereferenced value. The compiler doesn't object to either of the two following lines but it doesn't want me to combine them? The only difference I can see is I want the pointer to dereference a long instead of a byte and to increment by the same size. I can't think of any reason why it would make any difference if the pointer is in a register or not.
UInt8 value1 = *(ptr)++; UInt32 value2 = *((UInt32*) ptr);
gcc (in compilance with the C standard) considers ptr to be an lvalue (a left-hand value) for the purposes of the ++ postincrement, and gcc 4.0 is more strict about casts in lvalues. (Other gccs call this a hard error now; we're just warning). If you go to the C Oracle ( http://www.comeaucomputing.com/tryitout/) you'll get a similar warning/error.
The correct thing to do is to explicitly dereference the pointer type into a proper lvalue:
UInt32 value = *(*(UInt32 **)&ptr)++;
Chris
|