Enumeration erweitern

?

Original von Tom9811
Das ahnt er auch, wenn du -hannoSeppCornflakes schreibst.

Ja, passt ja auch nicht zusammen. Ist nicht gut für den Programmablauf.

Original von Tom9811
Aber was hat das mit const zu tun und damit, dass der Compiler (inkl. Optimierer) Prämissen anstellen darf?

Also, für mich ist ein NSString ein NSString. Ein Compiler, der mir ein NSString in ein NSSonstwas optimiert, welches nicht mehr der dokumentierten NSString Funktionalität entspricht, gehört in die Ablage P.

Michael

Original von kressevadder
Bums und schon auf die Nase gefallen

Der Zeiger auf die Konstante ist nur innerhalb der Instanz der Selbe!

Wie und vor allem wo hast Du denn kWLDragOperationNil definiert?

Michael

Ja, da dannn verschiedene INstanzen erzeugt werden können.

Scheint so als ist define wirklich so böse. Also Stringkonstanten definiere ich immer so:
In der Implementationsdatei:
In die Headerdatei kommt dann noch rein:
Dann ist der Zeiger überall gleich.

Michael

? Du sollst eine globale Variable anlegen. Ob mit const oder nicht spielt hierbei erst einmal keine Rolle.

Lass dir mal einen Identifier von Cocoa anzeigen.

Ich wittere ein Tutorial.

Äh, const ist eine Storage Class, keine Objective-C-Klasse.

const ist ein Typ-Qualifizierer, keine Speicherklasse. Ich sehe jetzt aber nicht, in wie weit das für die Verwendung einer NSString-Konstanten von Belang sein könnte, wo/wie die Konstante im Speicher liegt.

Michael

Das ist von Belang für

myIdentifier = …

Es hat gar nichts damit zu tun, wo es im Speicher liegt. Genauso wenig wie mit der Objective-C-Klasse. Damit hat das *rein und überhaupt gar nichts zu tun*. Weder damit, noch damit
Enumeration erweitern
oder damit
Enumeration erweitern
noch damit
Enumeration erweitern

Der Compiler weiß durch das const, dass eine Zuweisung verboten ist. Daher kann er alle Verwendungen von myIdentifier optimieren.

Ich sehe schon, dass das ein Tutorial ist.

Was ist 'myIdentifier' jetzt in dem Zusammenhang? Wir sprechen doch hier im Moment über das erste const, vor NSString, oder?

Michael

Das ist gleichgültig. Davor oder dahinter ändert es nichts an der Objective-C-Klasse. Dahinter sorgt es dafür, dass keine Zuweisungen an den Zeiger möglich sind. Davor sorgt es dafür, dass keine Zuweisungen an die Instanzvariablen möglich sind (hns). Das hat aber nicht mit Mutables und Immutables zu tun.
Selbst wenn MyMutableContainer als const (davor) deklariert wird, sagt das nichts darüber aus, ob sich der Inhalt verändert. Das hat mit Immutables und Mutables nichts zu tun. Diese Unterscheidung ist "inhaltlich". Damit der Compiler das beurteilen kann, müsste er meinen Code verstehen. Denn die Änderung kann ja auch über den Helfer geschehen. const (das davor) indessen ist eine formale Betrachtung als Hilfestellung des Programmierers an den Compiler, weil *dieser* seinen Code verstanden hat (*hoff*). IIRC wirft der Linke auch alle const-Sachen in ein eiigenes Segment. Müsste ich aber nachschauen. Das gibt der CPU die Möglichkeit eines absoluten Zugriffes. Auch weiß der Compiler, dass er als Parameter übergeben muss. (Was allerdings bei Objective-C wegen das late Dispatching nicht viel bringen dürfte.)

Erstes kann der Compiler sicher für Optimierungen verwenden. Bei Zweitem (also davor) könnte es sein, müsste man länger drüber nachdenken. Ich denke, dass es wenige Fälle gibt, in denen er damit etwas anfangen kann. Für den Alltagsgebrauch dürfte das keine Rolle spielen. Deshalb schrieb ich ja auch gestern, dass es nicht wichtig sei. Bei C und C++ ist es wichtig, weil du Objekte zuweisen kannst. Bei Objective-C geht das ja nicht.

2 Edit

Original von Tom9811
Das ist gleichgültig. Davor oder dahinter ändert es nichts an der Objective-C-Klasse.

Also, ich find es nicht gleichgültig, ob wir über das eine oder das andere Reden. Weil dann reden wir eventuell aneinander vorbei.

Original von Tom9811
Dahinter sorgt es dafür, dass keine Zuweisungen an den Zeiger möglich sind. Davor sorgt es dafür, dass keine Zuweisungen an die Instanzvariablen möglich sind (hns).

hns sagt auch, dass bei NSString-Konstanten das const vorweg überflüssig ist. Wieso darf er das und ich nicht? Und wieso macht Apple das so, wenn es denn so falsch ist?

Original von Tom9811

Quellcode

1. // vorgestellter immutable Container
2. // A little help from my friends.
3. @interface MyMutableMemCompressingBestFittingForInitializationWith16 : MyMutableMemCompressingBestFittingForInitialization {
4. void* memBlock;
5. }
6. @end
8. // the real stuff
9. @interface MyMutableContainer : NSObject {
10. MyMutableMemCompressingBestFittingForInitialization* object;
11. }
12. …
13. @end

Alles anzeigen

Wir reden aneinander vorbei, weil das hat mit NSString jetzt ganz und gar nichts mehr zu tun.

Michael

Zitat:
Original von Tom9811
Das ist gleichgültig. Davor oder dahinter ändert es nichts an der Objective-C-Klasse.

Also, ich find es nicht gleichgültig, ob wir über das eine oder das andere Reden. Weil dann reden wir eventuell aneinander vorbei.

Es ist gleichgültig dafür, ob ein NSString-Objekt eine NSString-Objekt ("Objective-C-Klasse") ist. Es ändert in keinem Falle die Objective-C-Klasse.

Zitat:hns sagt auch, dass bei NSString-Konstanten das const vorweg überflüssig ist. Wieso darf er das und ich nicht? Und wieso macht Apple das so, wenn es denn so falsch ist?

a) hns sagt, dass die Instanzvariablen nicht verändert werden dürfen. Er schlussfolgert daraus, dass const (davor) gleichgültig sei, weil die ohnehin privat sind.

Das ist nur teilweise richtig, weil bei einem const (so verstanden, wie von ihm gesagt) NSString *selbst* die Instanzvariablen nicht verändern dürfte, während @private den *äußeren* Zugriff beschreibt.

Ob das etwas konkret bringt, erschließt sich erst nach einem tiefen Blick in den gcc. Den haben wir alle drei nicht. (Und mutmaßlich auch keine Lust und keine Zeit dazu.)

b) Du hast nicht gesagt, dass es überflüssig sei. Das denke ich ja in den allermeisten Fällen selbst und habe es bereits gestern geschrieben. Du hast von Objective-C-Klassen gesprochen. Und damit hat es nichts zu tun. (Sagt übrigens auch hns.)

c) Apple wird es so machen, weil die in der Tat die Manpower (und interne Kenntnisse) haben, nachzuzprüfen, ob es in der konkreten Implementierung etwas bringt. Das können wir alle nicht. Aber wenn man darüber nachdenkt, dann sieht man, dass es bei Objective-C wohl eher unbedeutend ist. (Was ich seit gestern gesagt habe?)

Aber umgekehrt gefragt: Wieso lassen es die gcc-Leute zu, wenn es keine Auswirkungen hat?

Wir reden aneinander vorbei, weil das hat mit NSString jetzt ganz und gar nichts mehr zu tun.

Nein, in der Tat hat const mit NSString nichts zu tun. Wie auch static oder unsigned. Das muss man abstrahieren.

Original von Tom9811
b) Du hast nicht gesagt, dass es überflüssig sei.

Stimmt, ich habe "kann man sich sparen" gesagt.

Michael

Du hast gesagt: "NSString kann man sich sparen, weil NSString ja sowieso immutable ist."
Gegen den letzten Teil habe ich geschrieben, weil er -sorry- ziemlicher Unfug ist.

Ich habe ja deine Beiträge verlinkt …