On May 21, 2008, at 2:39 PM, Johnny Lundy [EMAIL PROTECTED] wrote:
Here's why the OP was not aware of the behavior of an NSArray class
method:
Here's the verbatim documentation for +arrayWithObjects:
[...deleted...]
See? Not a word about autoreleasing anything, or having to retain the
On May 21, 2008, at 12:37 PM, Johnny Lundy wrote:
This is just one example of that little tidbit that is always left
out of these references by Apple. It seems to be the .O. for some
reason. The tidbit isn't some extraneous bell or whistle; it's
always something fundamental.
They can't
If you've got complaints or suggestions for Documentation, then go to
http://bugreport.apple.com/ and file a bug. Apple seems intent on
working with these kinds of suggestions, esp. if they help newcomers
transition to the platform.
Sincerely,
Joe K.
On May 22, 2008, at 5:13 PM, Johnny Lundy wrote:
My point in using that class reference was simply to show how
someone could follow the manual and still have his code not work.
Actually, the introductory documentation never actually says that
the convenience constructors always return
You probably want to use a NSArrayController and bind the combo box to
that.
When you hit the buttons you change the array through the controller.
HTH
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or
You are not retaining the autoreleased array in your constructor. You
are over-riding the first initialization of your array(which is a
leak) while you are initializing with arrayWithObjects: call.
You can remove this line completely
cityArray = [[NSArray alloc] init];
and do a retain on
What you're doing here is allocating an empty array, and then setting the
pointer of your instance variable to a new array, created with the
arrayWithObjects message. An array returned by this message is
autoreleased, so at the end of your init method, it's being released. All
these type of
On May 21, 2008, at 12:05 PM, john darnell wrote:
- (id) init
{
cityArray = [[NSArray alloc] init];
NSString *c0 = @New York; //Ten NSString objects created here
...
NSString *c9 = @Virginia Beach;
cityArray = [NSArray arrayWithObjects: c0, ...c9, nil];
return self;
}
Here's
: Re: Trying to understand -- please help...
To: john darnell [EMAIL PROTECTED]
Ok, I'm somewhat of a beginner myself, but here's what I see.
First off: Your array is being 'emptied' because [NSArray
arrayWithObjects:]
returns an autoreleased array. You should retain this like so [[NSArray
Also, since the initializer methods of the superclasses aren't invoked
automatically for you, you should code your initializers using a
pattern along the lines of:
- init
{
if (self = [super init]) {
// ... initialization statements for the instance
variables of
Well
Something like this is standard :
- (id)init
{
if (!(self = [super init]))
return nil;
cityArray = [[NSArray alloc] initWithObjects:
@New York
...,
nil];
return self;
}
would
@lists.apple.com
Subject: Re: Trying to understand -- please help...
Well
Something like this is standard :
- (id)init
{
if (!(self = [super init]))
return nil;
cityArray = [[NSArray alloc] initWithObjects:
@New York
with an empty NSArray (not very useful, since you can't add items to
an NSArray). Then, you leak that allocated memory by setting cityArray
to an autoreleased NSArray
In fact it is not leaking, it is just creating an object for nothing, it will
be released by the autorelease pool, than no
On Wed, May 21, 2008 at 9:49 AM, Gérard Iglesias
[EMAIL PROTECTED] wrote:
with an empty NSArray (not very useful, since you can't add items to
an NSArray). Then, you leak that allocated memory by setting cityArray
to an autoreleased NSArray
In fact it is not leaking, it is just creating an
On Wed, May 21, 2008 at 9:47 AM, Peter Hudson [EMAIL PROTECTED] wrote:
The line of code [NSArray arrayWithObjects: c0, ...c9, nil]; produces
an array all right - but as you have used a class initializer, it will auto
release when you return from the method where it was created.
They are
On May 21, 2008, at 9:49 AM, Gérard Iglesias wrote:
with an empty NSArray (not very useful, since you can't add items to
an NSArray). Then, you leak that allocated memory by setting
cityArray
to an autoreleased NSArray
In fact it is not leaking, it is just creating an object for
nothing,
On May 21, 2008, at 12:49 PM, Gérard Iglesias wrote:
with an empty NSArray (not very useful, since you can't add items to
an NSArray). Then, you leak that allocated memory by setting
cityArray
to an autoreleased NSArray
In fact it is not leaking, it is just creating an object for
You probably want to use a NSArrayController and bind the combo box to that.
When you hit the buttons you change the array through the controller.
Folks please don't point someone at things like NSArrayController when
they are just getting started. Using controller layer / bindings can
make a
On Wed, May 21, 2008 at 12:47 PM, Peter Hudson [EMAIL PROTECTED] wrote:
The line of code [NSArray arrayWithObjects: c0, ...c9, nil]; produces
an array all right - but as you have used a class initializer, it will auto
release
when you return from the method where it was created.
No,
You also want to add a dealloc method to your class that releases
cityArray, something like:
- (void)dealloc
{
[cityArray release];
[super dealloc];
}
-- Ilan
On May 21, 2008, at 12:05 PM, john darnell wrote:
Hello Everyone:
I decided that it was time for a play period
On Wed, May 21, 2008 at 10:11 AM, Gérard Iglesias
[EMAIL PROTECTED] wrote:
Or am I missing something ?
Yes :)
You are misreading what he typed I inlined what he typed with the code...
- (id) init
{
// First, you allocate and initialize the cityArray with an empty
NSArray (not very useful,
Any initialiser with a + in front of it returns an autoreleased object
ACK! NO! A *method* with a + is a class method, whether it
returns an autoreleased object or nothing at all. Class methods that
return autoreleased objects are for convenience, but not all of them
do. Consider
Consider +(void)initialize ... also, *none* of them are
initializers by implication because they're class methods.
Sorry, these two sentences seem to be contradictory. Let me clarify:
+initialize is used to initialize the *class*. No class methods are
*instance* initializers or have anything
Nonsense.
Nonsense again.
Yet more nonsense.
Lets avoid this kind of tone in emails on this list... correct,
clarify, explain, etc. and leave it at that.
-Shawn
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin
On 21-May-08, at 11:37 PM, I. Savant wrote:
Consider +(void)initialize ... also, *none* of them are
initializers by implication because they're class methods.
Sorry, these two sentences seem to be contradictory. Let me clarify:
+initialize is used to initialize the *class*. No class
On May 21, 2008, at 11:35 AM, Johnny Lundy wrote:
Seriously, read that assuming you wanted to try out the NSArray
class and tell me how it accomplishes its purpose of documenting
what it is intended to document. It doesn't. And this pattern is
repeated over and over in just about every one
On Wed, May 21, 2008 at 11:35 AM, Johnny Lundy [EMAIL PROTECTED] wrote:
Here's why the OP was not aware of the behavior of an NSArray class method:
Here's the verbatim documentation for +arrayWithObjects:
arrayWithObjects:
Creates and returns an array containing the objects in the argument
What exactly do you mean by initializing the *class*? what exactly is
initialized with +initialize() method?
When exactly this method gets called?
Read the documentation!
On Wed, May 21, 2008 at 11:47 AM, Vijay Malhan [EMAIL PROTECTED] wrote:
What exactly do you mean by initializing the *class*? what exactly is
initialized with +initialize() method?
When exactly this method gets called?
Look for the subsection titles Initializing a Class Object
Vijay Malhan wrote:
What exactly do you mean by initializing the *class*? what exactly
is initialized with +initialize() method?
When exactly this method gets called?
If you are at all familiar with Java, this is the same thing as a static
initializer.
It sets up data required
The most common (albeit deprecated) example that immediately comes to
my mind is here:
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueObserving_Protocol/DeprecationAppendix/AppendixADeprecatedAPI.html#/
/apple_ref/occ/clm/NSObject/
Pretty soon, the documentation is going to be 80% repetition and 20% actual
unique-to-the-class content.
snip
I understand the frustration initially experienced by reading, say, the docs
to NSArray and not having every last detail spelled out. At the same time,
most of the details are
You troubles are all in this method and how you handle cityArray.
First you don't need to alloc and init a new array for cityArray as
[NSArray arrayWithObjects: c0, ...c9, nil] gives you a new one already
with the objects you specified.
Another thing you should watch for is there's an
Thanks for the pointers to the documentation. This is sample snippet from
the documentation.
@implementation MyClass
+ (void)initialize
{
if ( self == [MyClass class] ) {
/* put initialization code here */
}
}
If I'm not wrong self equivalent of this which points to an
On Wed, May 21, 2008 at 12:14 PM, Vijay Malhan [EMAIL PROTECTED] wrote:
Thanks for the pointers to the documentation. This is sample snippet from
the documentation.
@implementation MyClass
+ (void)initialize
{
if ( self == [MyClass class] ) {
/* put initialization code here
On May 21, 2008, at 3:37 PM, Johnny Lundy wrote:
I submit that any experienced programmer looking up and turning to a
page entitled NSArray Class Reference would expect that a
behavior of the class that results in one's created object being
deallocated out from under him would be
On Wed, May 21, 2008 at 2:48 PM, Bill Bumgarner [EMAIL PROTECTED] wrote:
I have taught/mentored/managed/reviewed/interviewed literally hundreds of
Cocoa programmers over the past two decades (counting Cocoa's NeXT produced
predecessors). My experience has been that the most successful Cocoa
Am 21.05.2008 um 18:34 schrieb Gérard Iglesias:
In fact in its original case, there would be a crash, because
cityArray would point to a trashed pointer... I don't understand why
it is not crashing.
Well, it's not a trashed pointer. The memory has been alloced (and
self is set already),
On Wed, May 21, 2008 at 3:37 PM, Johnny Lundy [EMAIL PROTECTED] wrote:
I submit that any experienced programmer looking up and turning to a page
entitled NSArray Class Reference would expect that a behavior of the
class that results in one's created object being deallocated out from under
Am 21.05.2008 um 18:47 schrieb Peter Hudson:
Any initialiser with a + in front of it returns an autoreleased
object
NO! Several mistakes in this sentence:
1) + simply means that it is a method of the class, not of
individual instances. It has NOTHING to do with whether the result is
On Wed, May 21, 2008 at 3:14 PM, Vijay Malhan [EMAIL PROTECTED]
wrote:
Thanks for the pointers to the documentation. This is sample snippet from
the documentation.
@implementation MyClass
+ (void)initialize
{
if ( self == [MyClass class] ) {
/* put initialization code here
On May 21, 2008, at 10:36 AM, Sherm Pendley wrote:
[Objects] are simply released when the autorelease pool they are
created in is released - which you can treat as occurring at the
end of the method in which the init occurs.
Nonsense again. The autorelease pool is emptied at the end of
On Wed, May 21, 2008 at 7:35 PM, Johnny Lundy [EMAIL PROTECTED] wrote:
All it would take is a single sentence under the Class Methods header, to
say that these methods autorelease the returned object (AND that such
autoreleasing means that the object will be deallocated if the method in
which
On Wed, May 21, 2008 at 1:32 PM, Shawn Erickson [EMAIL PROTECTED] wrote:
Folks please don't point someone at things like NSArrayController when
they are just getting started. Using controller layer / bindings can
make a lot of things easier and cleaner code (heck no code) but it
really
On May 21, 2008, at 1:35 PM, Johnny Lundy wrote:
All it would take is a single sentence under the Class Methods
header, to say that these methods autorelease the returned object
(AND that such autoreleasing means that the object will be
deallocated if the method in which it was created
On Wed, May 21, 2008 at 5:06 PM, Christopher Nebel [EMAIL PROTECTED]
wrote:
On May 21, 2008, at 10:36 AM, Sherm Pendley wrote:
[Objects] are simply released when the autorelease pool they are created
in is released - which you can treat as occurring at the end of the method
in which the
On May 21, 2008, at 2:45 PM, Shawn Erickson wrote:
Nonsense.
Nonsense again.
Yet more nonsense.
Lets avoid this kind of tone in emails on this list...
Yes, please.
--Andy
correct,
clarify, explain, etc. and leave it at that.
-Shawn
___
On 21 May '08, at 12:37 PM, Johnny Lundy wrote:
I submit that any experienced programmer looking up and turning to a
page entitled NSArray Class Reference would expect that a
behavior of the class that results in one's created object being
deallocated out from under him would be
On 21 May '08, at 12:14 PM, Vijay Malhan wrote:
If I'm not wrong self equivalent of this which points to an
instance
var. And it is initialized in - init (instance)method. And if it
fails to
initialize, it's nil. So does self even exist when + initialize is
called.
This is a class
On 21 May '08, at 11:35 AM, Johnny Lundy wrote:
See? Not a word about autoreleasing anything, or having to retain
the returned array. Nada.
It also didn't spell out that:
the return value is a pointer,
pointers are 4 or 8 bytes large,
the pointer value zero is special and is named nil,
Would be like a cookbook including instructions on how to operate an
oven and use a knife to cut vegetables in every single recipe. I
think most would find that pretty redundant and diluting, especially
when the preface covers these topics in detail.
On May 21, 2008, at 8:37 PM, Jens
51 matches
Mail list logo
