Thanks. So a C array property is not possible.
No. Think about what it would take to handle a set on this property. If you pass in another c-style array, what would you do? Copy the contents? How many bytes?
You COULD have an int * property that you use to store the base of an array, but memory management would be a nightmare.
-Lee
A c-style array or an NSArray? The latter should be fine, the firmer doesn't make sense, because you can't change a fixed-dimension array with an assignment, etc.
No. Think about what it would take to handle a set on this property. If you pass in another c-style array, what would you do? Copy the contents? How many bytes?
Why would this not make sense? The only caveat is that the C-style array property would have to be declared as assign, not retain. Otherwise it's perfectly fine. There's no problem with it being fixed-dimension; an NSArray is fixed-dimension, too.
int main(int argc, char *argv) {
int x[5];
int y[5];
y[0]=3;
y[2]=4;
x=y;
}
Why are you making this so complicated? For an NSArray, setting the property doesn't copy the contents. You're just copying the array pointer itself. Same deal with a C-style array.
The code above does not compile.
If you use an automatic variable as shown in my example above to "set" the address of this property, once the stack frame the array was declared in is popped, this memory is being used for something else.
If you pass in a dynamically allocated chunk of memory from malloc, now you have the issue of when to free that chunk. The next time something sets this property?
How would the message receiver distinguish whether the array it receives as a parameter is stack-allocated or not? If it can't distinguish them, then how can it be written to work reliably?Which is why stack-allocated arrays should not be assigned to a property.
That doesn't mean a C-style array property "doesn't make sense", and it's certainly possible, contrary to what you were implying.
because that's what the OP was trying, and because it's a rather popular way to declare an array. A pointer in and of itself may be the base of an array or point to one value. I wouldn't see int * and say that it's an array. Also, in terms of length, you do statically allocate an NSArray. I'm guessing you meant heap-vs.-stack, which isn't even a question in Objective-C. Blocks are the only objects that can be stack-resident.Of course not. Why are you statically allocating the arrays? You don't statically allocate an NSArray, do you? Apples to apples...
Which is why stack-allocated arrays should not be assigned to a property.
I said that arrays declared with a fixed size was not possible, because that's what the OP asked. This is true. Jared_kipe and I also stated that a pointer can be used as a property, to which the base of an array could be assigned. It's just ill-advised, which I am still convinced of. Mixing malloc/free and retain/release presents challenges above what one would face trying to do either independently. The proper handling all cases would be a bear. You may have a great solution in the bag already (which chown33 asked you to share), but most people don't.The fact that malloc/free requires a different style of management than retain/release is irrelevant. That doesn't mean a C-style array property "doesn't make sense", and it's certainly possible, contrary to what you were implying.
How would the message receiver distinguish whether the array it receives as a parameter is stack-allocated or not? If it can't distinguish them, then how can it be written to work reliably?
Post example code, please. I'm curious to see how you'd handle the lifetime issue lee1210 mentioned.
@interface MyObject : NSObject {
char *array;
}
@property (nonatomic, assign) char *array;
@end
@implementation MyObject
@synthesize array;
@end
@interface MyAppDelegate : NSObject <NSApplicationDelegate> {
MyObject *object;
}
@end
@implementation MyAppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
object = [[MyObject alloc] init];
char *array = malloc(1024);
object.array = array;
}
- (void)applicationWillTerminate:(NSNotification *)aNotification {
free(object.array);
[object release];
}
@end
I'm also wondering how you'd ... reliably communicate the array's length (number of elements).
because that's what the OP was tryingOf course not. Why are you statically allocating the arrays?
You and I know that, but others might not. There are many new programmers in these parts who may not be aware of the pitfalls of passing a pointer to a stack-local variable to something that might outlive the stack frame.Which is why stack-allocated arrays should not be assigned to a property.
I said that arrays declared with a fixed size was not possible, because that's what the OP asked.
It's just ill-advised, which I am still convinced of.
By way of the error message. You get that with a fixed-size array, not with a pointer.Where did the OP say he was statically allocating the arrays?
So? You can shoot yourself in the foot with the reference counting of NSArrays, too. New programmers (and old ones!) might call release once too often or retain once too often. Does that mean NSArrays as properties are "not possible"?
No, the OP never mentioned anything about fixed-size arrays.
I couldn't agree more. But "ill-advised" and "not possible" are two very different things. And in fact, you seem to have gotten the OP thinking that C arrays as properties are not possible at all. That's what I was objecting to.