Enumeration erweitern

Dort trifft das dann nimmer zu

Wie kommst du darauf, dass man bei einem definierten Key aus ener Headerdatei man etwas anderes verwenden darf als einen definierten Key aus einer Headerdatei?

Du fängst doch auch nicht an, statt NSObservedObjectKeyPath auf einmal @"NSObservedObjectKeyPath" zu schreiben. Da beißt nicht ich mir in den Arsch, sondern der Dritte bekommt von mir ne Mail, in der erläutert wird, was der Sinn globaler Konstanten ist. Genausowenig fängst du doch an, statt kABPersonName auf einmal 5+8 oder was weiß ich zu schreiben. Auch in diesem Falle würde man sich übrigens früher oder später in den Arsch beißen. (Oder eine Mail von mir bekommen.)

@kresse #define ist böse. Nimm eine NSString-Konstante.
Bei eigenen Konstanten müsste sogar ein doppelts const gehen:Aber das ist nicht wirklich wichtig.

Aber das ist immer der Selbe.

Das ist der große Vorteil von Immutables. Man darf das nicht unterschätzen. Die Beispiele mit NSNumber hatten wir ja auch schon.

Klar, die landen ja gesammelt in einem Segment. Möglicherweise ist NSString sogar so schlau, bei Instantierung erst nachzuschauen, so dass es sogar von Platte funktioniert. Was jedoch gar nicht geht, das hoffe ich jedenfalls:
Aber man darf wirklich nicht unterschätzen, was an Möglichkeiten existiert, wenn das Framework davon ausgehen kann, dass sich ein Container nicht verändert.

Original von gritsch

Original von læng
warum ist da kein if (self == aString) return YES; drin?

Gute Frage. In meiner mySTEP-Variante habe ich es drin. Ich gebe es mal an die GNUstepper weiter...

Geändert: in der *neuesten* Version ist es drin. D.h. Du hast ein veraltetes GNUstep.

-- hns

Was ich an NSString-Konstanten nicht mag ist, dass ich immer von const NSString * nach NSString * casten muss, wenn ich sie einer Methode übergebe.

Ja, wobei das zweite const immer geht.

Was bewirkt das denn?

Das zweite const macht die Zeigervariable konstant. Das heißt, Du kannst der Zeigervariablen keinen anderen String zuweisen und kannst sicher sein, dass die Zeigervariable immer auf die Stringkonstante zeigt. Das const vor NSString kann man sich sparen, weil NSString ja sowieso immutable ist. Cocoa definiert Stringkonstanten auch nur mit dem zweiten const. Dann braucht man auch nicht bei Übergabe an eine Methode casten.

Michael

Ob der Compiler weiß, dass NSStrings konstant sind?

Aber es wird in der Tat nicht viel bringen.

Original von Tom9811
Ob der Compiler weiß, dass NSStrings konstant sind?

Meiner ahnt zumindest etwas:
:]

Michael

Meiner ahnt zumindest etwas:

Ich glaube nicht, dass der gcc eine Klartext-Englisch-Analyse hat. Das können wir frühestens in drei, vier Jahren erwarten.

Er ahnt eher, dass es die Buchstabenkombination appendString: kein Bezeichner einer Methode ist. Mit konstant hat das erst einmal nichts zu tun.

Original von Tom9811
Er ahnt eher, dass es die Buchstabenkombination appendString: kein Bezeichner einer Methode ist. Mit konstant hat das erst einmal nichts zu tun.

Es reicht jedenfalls mir mitzuteilen, dass da was nicht zusammen passt.

Michael

Original von Michael

Original von Tom9811
Ob der Compiler weiß, dass NSStrings konstant sind?

Meiner ahnt zumindest etwas:

Quellcode

1. warning: 'NSString' may not respond to '-appendString:'

:]

Michael

Das ist etwas anderes. Er ahnt nicht nur sondern weiß daß Stringkonstanten nicht von NSMutableString abgeleitet sind... Deshalb kennt er die Methode nicht.

-- hns

Original von læng
Was ich an NSString-Konstanten nicht mag ist, dass ich immer von const NSString * nach NSString * casten muss, wenn ich sie einer Methode übergebe.

const NSString *xxx ist überflüssig - und sagt dem Compiler daß einzelne Instanzvariablen nicht geändert werden dürfen. NSString hat aber sowieso nur private...

NSString *const xxx macht Sinn und sagt dem Compiler daß das nicht auf der linken Seite einer Zuweisung stehen darf - weil Konstant.

-- hns

Na, ich meine, dass es auch bedeutet, dass niemand (also auch NSString-Instanzen selbst!) die Instanzvariablen nicht ändert. Das ist wichtig beim Threading. Auch bei Zuweisungen kann das eine Rolle spielen, wobei ja Objective-C ohnehin keine Objekt-Zuweisung kennt, so dass sich das erübrigt. Bei C++ ist das relevant.

Wie aber bereits gestern gesagt, ist das nicht wirklich wichtig. Man müsste mal genau nachschauen, ob es überhaupt etwas bringt.

Es reicht jedenfalls mir mitzuteilen, dass da was nicht zusammen passt.

?

Das ahnt er auch, wenn du -hannoSeppCornflakes schreibst. Aber was hat das mit const zu tun und damit, dass der Compiler (inkl. Optimierer) Prämissen anstellen darf?

%p bitte