https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html#//apple_ref/doc/uid/TP40011210-CH5-SW3
and scroll up about half a page:
"Properties Are Atomic by Default"
gerd
On Apr 7, 2014, at 6:56 PM, Graham Cox wrot
On 8 Apr 2014, at 6:11 am, Greg Parker wrote:
> No. atomic is the default everywhere.
Do you have a reference for the relevant documentation? I don't know if it's a
reflection on me or Xcode's doc search, but I simply couldn't find it (though
I'm pretty sure I have read it somewhere).
--Gra
On Apr 7, 2014, at 1:52 AM, Kevin Meaney wrote:
> I thought the behaviour was different between iOS and MacOS. On iOS nonatomic
> was the default and atomic on OS X.
No. atomic is the default everywhere.
The only OS difference is that the iOS SDK tends to use nonatomic more than the
OS X SDK.
I thought the behaviour was different between iOS and MacOS. On iOS nonatomic
was the default and atomic on OS X.
Kevin
Sent from my iPhone
On 7 Apr 2014, at 05:28, Graham Cox wrote:
>
> On 7 Apr 2014, at 1:58 pm, Ben Kennedy wrote:
>
>> t is for these two reasons that, from years of condi
On Apr 6, 2014, at 11:28 PM, Graham Cox wrote:
> On 7 Apr 2014, at 1:58 pm, Ben Kennedy wrote:
>
>> t is for these two reasons that, from years of conditioning, I can watch my
>> fingers type "(nonatomic " automatically and as if my magic as soon as I
>> finish typing "@property " ...
>
> Me
On 7 Apr 2014, at 1:58 pm, Ben Kennedy wrote:
> t is for these two reasons that, from years of conditioning, I can watch my
> fingers type "(nonatomic " automatically and as if my magic as soon as I
> finish typing "@property " ...
Me too, though it's been more to do with the fact that I don'
On 06 Apr 2014, at 8:44 pm, Graham Cox wrote:
> I thought about mentioning it, but figured it might already sound a bit
> complicated. Isn't 'nonatomic' the default? If not, I can't actually find the
> documentation about it. Also, if 'atomic' is the default, won't performance
> suffer with al
On 7 Apr 2014, at 1:25 pm, Ken Thomases wrote:
> Usually, it's better/easier to simply declare the property nonatomic.
I thought about mentioning it, but figured it might already sound a bit
complicated. Isn't 'nonatomic' the default? If not, I can't actually find the
documentation about it.
Thanks guys, really appreciate it.
On 7/04/2014 1:25 pm, "Ken Thomases" wrote:
>On Apr 6, 2014, at 9:18 PM, Graham Cox wrote:
>
>> On 7 Apr 2014, at 10:35 am, Varun Chandramohan
>> wrote:
>>
>>> @property (retain) NSArray* contents;
>>
>> Should be:
>>
>> @property (copy) NSArray* contents;
>
On Apr 6, 2014, at 9:18 PM, Graham Cox wrote:
> On 7 Apr 2014, at 10:35 am, Varun Chandramohan
> wrote:
>
>> @property (retain) NSArray* contents;
>
> Should be:
>
> @property (copy) NSArray* contents;
> @synthesize contents = ivarContents;
>
> Having done that you'll now only have one ivar
On 7 Apr 2014, at 10:35 am, Varun Chandramohan
wrote:
> Hi Graham,
>
> Thank you for such detailed explanation. I made a few changes except the
> type check of what NSPropertyListSerialization returns. Ill be adding that
> soon. Other than that, I wanted you to take a look at the changes I mad
Hi Graham,
Thank you for such detailed explanation. I made a few changes except the
type check of what NSPropertyListSerialization returns. Ill be adding that
soon. Other than that, I wanted you to take a look at the changes I made
and let me know if you see any problems. I tested it, at it seems
On Apr 3, 2014, at 8:22 PM, Varun Chandramohan
wrote:
> Interestingly, the static code analysis find the call of "retain" as a leak.
> How do I address this issue? What is correct way to rewrite this code to make
> static analyser understand that I will be releasing the resource? If I
> remove
On 4 Apr 2014, at 2:40 pm, Graham Cox wrote:
> Thirdly, casting the return value of [NSPropertyListSerialization
> propertyListWithData...] to NSMutableArray doesn't turn that object into a
> mutable array - you've just forced the type system to stop helping you.
> Certainly retaining it here
On 4 Apr 2014, at 2:22 pm, Varun Chandramohan
wrote:
> @property (assign) NSMutableArray* contents;
>[config setContents:(NSMutableArray *)[[NSPropertyListSerialization
>
> propertyListWithData:plistXML
>
>
Agreed.
I just meant in the general case.
ScottB
On Oct 13, 2011, at 11:30 , David Rowland wrote:
> However, if the property is readonly I think you must use direct access to
> set an initial value. The setter does not exist.
>
>
> David Rowland
>
> On Oct 13, 2011, at 10:54 AM, Bayes Scot
However, if the property is readonly I think you must use direct access to set
an initial value. The setter does not exist.
David Rowland
On Oct 13, 2011, at 10:54 AM, Bayes Scott F wrote:
> Thank you, David.
>
> Sounds like safety first for my code: always use the setter/getter for
> synthe
Thank you, David.
Sounds like safety first for my code: always use the setter/getter for
synthesized properties, even in self.
Or use ivars.
ScottB
On Oct 12, 2011, at 09:21 , Bayes Scott F wrote:
> Someone on Matt's site mentioned the possibility that the synthesized ivar
> could be impleme
Thanks, Greg.
ScottB
On Oct 12, 2011, at 12:12 , Greg Parker wrote:
> On Oct 12, 2011, at 9:21 AM, Bayes Scott F wrote:
>> Someone on Matt's site mentioned the possibility that the synthesized ivar
>> could be implemented indirectly, say as a member of a collection. Since the
>> implementatio
On Oct 12, 2011, at 9:21 AM, Bayes Scott F wrote:
> Someone on Matt's site mentioned the possibility that the synthesized ivar
> could be implemented indirectly, say as a member of a collection. Since the
> implementation's opaque, we don't know if that ever can happen.
A property may be impleme
Thank you, David, that's pretty clear.
Sounds like safety first for my code: always use the setter/getter for
synthesized properties, even in self.
Or use @private ivars.
ScottB
On Oct 12, 2011, at 09:46 , David Duncan wrote:
> On Oct 12, 2011, at 9:21 AM, Bayes Scott F wrote:
>
>> Someone o
On Oct 12, 2011, at 9:21 AM, Bayes Scott F wrote:
> Someone on Matt's site mentioned the possibility that the synthesized ivar
> could be implemented indirectly, say as a member of a collection. Since the
> implementation's opaque, we don't know if that ever can happen.
I can't say that I know
Someone on Matt's site mentioned the possibility that the synthesized ivar
could be implemented indirectly, say as a member of a collection. Since the
implementation's opaque, we don't know if that ever can happen.
So, is self->mySynthIvar safe (both lvalue and rvalue), or should we be
messagin
On Oct 11, 2011, at 9:57 AM, Matt Neuburg wrote:
> I did everything "right" when I named an ivar "firstResponder" (property,
> synthesized ivar, synthesized accessors) and totally broke my app because
> Apple was apparently already using an undocumented ivar called
> "firstResponder".
>
> http
On Fri, 07 Oct 2011 19:46:17 -0400, Andy Lee said:
>On Oct 3, 2011, at 2:23 PM, Charles Srstka wrote:
>> 2. KVOs access instance variables directly (mis)feature recognizes the
>> underscore prefix. I like to give it a prefix that KVO doesnt know about so
>> that I can be sure never to end up
On Oct 3, 2011, at 2:23 PM, Charles Srstka wrote:
> 2. KVO’s “access instance variables directly” (mis)feature recognizes the
> underscore prefix. I like to give it a prefix that KVO doesn’t know about so
> that I can be sure never to end up accidentally accessing the ivars of
> another object w
On Oct 7, 2011, at 11:40 AM, Sean McBride wrote:
> On Mon, 3 Oct 2011 13:23:25 -0500, Charles Srstka said:
>
>> 1. Apple reserves the underscore prefix for their own use, so you could,
>> at least theoretically, clash with a superclass ivar this way, and
>
> In addition to what Kyle replied, I'd
On Fri, 7 Oct 2011 10:21:41 -0700, Glenn L. Austin said:
>Do I really need to quote the C and C++ standards that states that a
>leading underscore on a symbol is reserved to the implementation -- in
>other words 'the implementation' is everything that you're not writing?
ISO/IEC 9899:1999, Sectio
On Oct 7, 2011, at 9:40 AM, Sean McBride wrote:
> On Mon, 3 Oct 2011 13:23:25 -0500, Charles Srstka said:
>
>> 1. Apple reserves the underscore prefix for their own use, so you could,
>> at least theoretically, clash with a superclass ivar this way, and
>
> In addition to what Kyle replied, I'd
> In addition to what Kyle replied, I'd just like to point out that prefixing
> your *methods* with an underscore is a very bad idea, since Apple does
> reserve such names and a conflict will bite you at runtime possibly affecting
> the binary compatibility of your app.
I would argue that under
On Mon, 3 Oct 2011 13:23:25 -0500, Charles Srstka said:
>1. Apple reserves the underscore prefix for their own use, so you could,
>at least theoretically, clash with a superclass ivar this way, and
In addition to what Kyle replied, I'd just like to point out that prefixing
your *methods* with an
On Mon, Oct 3, 2011 at 2:01 PM, Andreas Mayer wrote:
>
> Am 03.10.2011 um 16:14 schrieb John Tsombakos:
>
>> audioPlayer = [self getSoundFile:"soundfile.wav"];
>> ...
>>
>> in getSoundFile routine:
>> AVAudioPlayer *snd;
>> ...
>> snd = [[[AVAudioPlayer alloc] initWithContentsOfURL:url error:&erro
On Oct 3, 2011, at 1:31 PM, Kyle Sluder wrote:
>> 1. Apple reserves the underscore prefix for their own use, so you could, at
>> least theoretically, clash with a superclass ivar this way, and
>
> [snip]
>
>>
>> 3. If I use an ivar prefix that no one else uses (as far as I know), then I
>> ca
On Mon, Oct 3, 2011 at 11:23 AM, Charles Srstka
wrote:
> 1. Apple reserves the underscore prefix for their own use, so you could, at
> least theoretically, clash with a superclass ivar this way, and
[snip]
>
> 3. If I use an ivar prefix that no one else uses (as far as I know), then I
> can ma
On Oct 3, 2011, at 10:14 AM, John Tsombakos wrote:
> (and will also change to use the underscore ivar names too - I had done that
> previously, but...well, didn't this time.)
I recommend using some other prefix system instead of the underscore, for two
reasons:
1. Apple reserves the underscore
Am 03.10.2011 um 16:14 schrieb John Tsombakos:
> audioPlayer = [self getSoundFile:"soundfile.wav"];
> ...
>
> in getSoundFile routine:
> AVAudioPlayer *snd;
> ...
> snd = [[[AVAudioPlayer alloc] initWithContentsOfURL:url error:&error]
The question was already answered, but I wanted to point out
On Mon, Oct 3, 2011 at 10:29 AM, Steve Sisak wrote:
>> At 10:14 AM -0400 10/3/11, John Tsombakos wrote:
>> @interface AudioPlayerViewController : UIViewController {
>> AVAudioPlayer *audioPlayer;
>> }
>> @property (retain) AVAudioPlayer *audioPlayer;
>>
>> In the .m file:
>> @synthesize audioPlaye
Not enough morning coffee for you,
On Oct 3, 2011, at 7:29 AM, Steve Sisak wrote:
> You do, indeed want:
>
> self.audioPlayer = [self getSoundFile:"soundfile.wav"];
>
> or
>
> [self setAudioPlayer = [self getSoundFile:"soundfile.wav"]];
I think you meant [self setAudioPlayer:[self getSoundFil
At 10:14 AM -0400 10/3/11, John Tsombakos wrote:
@interface AudioPlayerViewController : UIViewController {
AVAudioPlayer *audioPlayer;
}
@property (retain) AVAudioPlayer *audioPlayer;
In the .m file:
@synthesize audioPlayer;
in viewDidLoad:
audioPlayer = [self getSoundFile:"soundfile.wav"];
You
On Jun 8, 2011, at 10:15 AM, Jonathan Taylor wrote:
> The objects are retained and released correctly if I set this property to a
> new value, or to nil. However when the parent object is deallocated, no
> release is sent to the latestFrame object. I don't know if this is expected
> behaviour
On Mon, Jan 4, 2010 at 10:34 AM, Alexander Reichstadt wrote:
> I can hardly expect for this to be a Cocoa-bug but imagine I am
> misunderstanding something. Can anyone help and please tell me where I am
> erring here?
You're expecting -retainCount to return a useful number. It doesn't.
Have a l
On Mon, Nov 16, 2009 at 5:18 AM, Austin Ziegler wrote:
> Is that true anymore, though? I've been looking at a lot of sample
> code lately, and it's very common practice to use "self.foo = ..." in
> initializers, even when they're declared nonatomic. I know you said
> you don't subscribe to it, but
On Sun, Nov 15, 2009 at 10:35 AM, Clark Cox wrote:
> On Sat, Nov 14, 2009 at 11:35 PM, Ariel Feinerman
> wrote:
>> 2009/11/15 Kyle Sluder
>>> On Sat, Nov 14, 2009 at 2:35 PM, Ariel Feinerman
>>> wrote:
>>> > I need two versions of -initWith ... and -set ... methods of custom timer
>>> > class
On Sat, Nov 14, 2009 at 11:35 PM, Ariel Feinerman wrote:
> 2009/11/15 Kyle Sluder
>
>> On Sat, Nov 14, 2009 at 2:35 PM, Ariel Feinerman
>> wrote:
>> > I need two versions of -initWith ... and -set ... methods of custom timer
>> > class (for example, to prevent the circle references);
>>
>> Do no
2009/11/15 Kyle Sluder
> On Sat, Nov 14, 2009 at 2:35 PM, Ariel Feinerman
> wrote:
> > I need two versions of -initWith ... and -set ... methods of custom timer
> > class (for example, to prevent the circle references);
>
> Do not use accessors in your initializers or -dealloc.
>
Hm, it means t
On Sat, Nov 14, 2009 at 2:35 PM, Ariel Feinerman wrote:
> I need two versions of -initWith ... and -set ... methods of custom timer
> class (for example, to prevent the circle references);
Do not use accessors in your initializers or -dealloc.
--Kyle Sluder
__
On Jul 10, 2009, at 2:19 AM, Half Activist wrote:
I'm loading a NIB file at runtime and use a new instance of a class
as its owner each time.
Everything works fine, until I wish to delete an object.
In my software, i'm using several instances of objects that have
their own
Yeah, but I figured that's more of a minor detail. When you're getting
started you just don't want it to crash; doesn't matter too much when
the crash actually occurs.
On 24 Oct 2008, at 16:33, Dave Carrigan wrote:
On Oct 24, 2008, at 8:23 AM, Mike Abdullah wrote:
NSString w = [NSString
On Oct 24, 2008, at 8:23 AM, Mike Abdullah wrote:
NSString w = [NSString stringWithFormat:@"something %i", x];
// Do stuff
[w release];// Will crash here
To be pedantic, it won't crash right there. It will crash sometime
later in a place completely unrelated to the location that you
I've done stuff like this by accident but doesn't it actually crash
later on when the auto release pool runs to release memory and not
actually at the release?
This is a good use of NSZombies if you have strange crashes.
Devon
Mike Abdullah wrote:
BUT NOT:
NSString w = [NSString stringWit
This sort of question comes up every couple of weeks. You did not use
+alloc to create the string, so you do NOT need to release it. If you
try to release it, the app will crash. Any of these are correct:
NSString w = [NSString stringWithFormat:@"something %i", x];
// Do stuff
NSString w =
It depends on the lifetime of w (which is an NSString*?) is supposed
to live.
If you have:
void foo() {
NSString* w = [NSString stringWithFormat:@"something %i", x];
bar(w);
}
Then the answer is: You do not have to retain w (the above code is
co
All answers you need are in this guide:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html
Le 24 oct. 08 à 07:24, Ron Green a écrit :
If I call NSString w = [NSString stringWithFormat:@"something %i", x];
Am I now suppose to call retain on w?
Wh
53 matches
Mail list logo
