wat betekent het om een ​​NSNumber-variabele te declareren als eigendomsexemplaar

Ik ben nog aan het leren ..., dus voor de volgende woning

@property (copy) NSNumber *foo;

Wat de kopie echt doet? een kopie maken van de (waarde van) foo en deze op een nieuwe plek zetten? Net als een kopie-aannemer?

En ook om te verduidelijken, doet het volgende in feite een AddRef, toch?

@property (retain) NSNumber *foo;
0

2 antwoord

See the description of properties here: http://cocoacast.com/?q=node/103

copy means that assigning a value into the property will make a copy of the input value.

retain means that you won't get an actual copy; you'll get the same object with an extra retain on it. So if it's modified elsewhere, you'll see the modifications in both places.

Voor NSNumber s zijn ze onveranderlijk, dus kopiëren en behouden zijn functioneel equivalent.

1
toegevoegd

Wat doet de kopie?

Over het algemeen is NSNumber onveranderlijk - ik verwacht dat kopie in die gevallen wordt geïmplementeerd met behouden :

- (id)copyWithZone:(NSZone*)zone {
  return [self retain];
}

En ook om te verduidelijken, doet het volgende in feite een AddRef, toch?

Welnu, door het te synthetiseren wordt de referentie-tellende boilerplate toegevoegd - de eigenlijke bewerking is complexer en neemt de gegeneraliseerde vorm aan:

- (void)setFoo:(NSNumber *)arg {
  NSNumber * prev = foo;
  foo = [arg retain];//<< or foo = [arg copy]; if you have specified 'copy'
  [prev release];
}
0
toegevoegd
Natuurlijk, als je niet-atomisch vs atomisch gebruikt, verandert de standaardplaat. niet-atomair komt dichter bij de bovenstaande code. Omdat je niet-atomair hebt gespecificeerd, zullen er ook @synchronize-oproepen onder de motorkap plaatsvinden. stackoverflow.com/questions/588866/&ellicle;
toegevoegd de auteur Tom Andersen, de bron
niet-atomaire ==> code wordt alleen vanaf een enkele thread gebeld. zonder het niet-atomaire sleutelwoord, is de code meer thread safe, of beter als je staat om thread safe code te schrijven met atomaire getters en setters.
toegevoegd de auteur Tom Andersen, de bron
@Tom Anderson Ja, ik weet dat het voorbeeld lijkt op niet-atomaire implementatie (maar de jouwe is een fijne opmerking voor anderen). De reden voor dit? Dit is een Cocoa-vraag voor beginners en ik zei dat het voorbeeld een gegeneraliseerde vorm is van wat er gebeurt (binnen de context van de vraag).
toegevoegd de auteur justin, de bron
Enkele opmerkingen over uw andere opmerkingen: 1) niet-atomaire eigenschappen kunnen draadveilig zijn en kunnen werken in multithread-contexten. We waren immers in staat om threadsafe gelijktijdige Cocoa-programma's te maken voorafgaand aan ObjC-V2. 2) Atomaire eigenschappen zijn niet geïmplementeerd met @ gesynchroniseerd . Dit is een populaire misvatting - het betekent ook dat programma's die a) @ gesynchroniseerd en b) verwachten dat atoomeigenschapimplementaties ook zullen gebruiken veel gelijktijdige ontwerpfouten hebben die wachten om gevonden te worden. (Vervolg)
toegevoegd de auteur justin, de bron
(vervolg) 3) Atoom eigenschappen vormen geen vervanging voor de juiste draadveiligheid. Ze beschermen alleen gegevens in een zeer beperkte omvang. Atomaire eigenschappen alleen zijn nog steeds onbetwistbaar onveilig in gelijktijdige uitvoering - ze verminderen alleen de kans dat een threading-fout optreedt (of wordt blootgesteld) tijdens de uitvoering. Dat is zelfs niet wenselijk - IMO, ik heb liever dat het defect eerder werd blootgelegd en vaker voorkomt omdat fouten in gelijktijdige programma's vreselijk moeilijk te reproduceren zijn. (Vervolg)
toegevoegd de auteur justin, de bron
(vervolg) De kern is: atomaire eigenschappen + @ gesynchroniseerd zijn echt geen goede oplossingen voor niet-triviale gelijktijdige programma's. Onder deze omstandigheden zijn noch atomaire eigenschappen noch @ gesynchroniseerd ideaal.
toegevoegd de auteur justin, de bron