Elementlänge in <typedef enum>

Original von fwtag

Original von gritsch
aber das ist ja eigentlich auch egal denn wer macht schon einen pointervergleich bei objekten...

kressevadder, hat er doch geschrieben

viele wege führen nach rom

aber das ist ja eigentlich auch egal denn wer macht schon einen pointervergleich bei objekten...

Ich war jung und dachte, ich müsste die Geschwindigkeit etwas optimieren. Allerdings ist mir dann aufgefallen, als ich bei GNUStep in den Code geschaut habe, das isEqualToString: erst mal was macht? Einen Pointervergleich!

Noch einmal zum urspruenglichen Problem:
Wenn ich mich recht erinnere, kann man dem gcc mit einem Flag mitteilen, was fuer ein Typ enums immer haben sollen. Nicht so schoen, aber immerhin.

Typennamen wie "uint8_t" sind uebrigens, wenn ich mich recht erinner, C99 standard, und daher _nicht_ offiziell Teil von C++ und evtl. auch nicht offiziell von Objective-C.

Original von gritsch

Original von Amin Negm-Awad
Pointervergleiche sind hier zulässig (jedenfalls bei extern const), da es in der Tat um denselben Marker geht.

Danke für den Hinweis. Das hatte ich noch nie hinbekommen.

aber rein theoretisch müsste es mit #define ja auch den gleichen pointer geben!?

Ich bin auch etwas verwundert. Letztlich gibt es da aber keine Garantie. Ich kenne jedenfalls keine. Bei einem extern const habe ich die Garantie, weil ich ja nur eine Definition habe.

Original von gritsch
aber das ist ja eigentlich auch egal denn wer macht schon einen pointervergleich bei objekten...

Hoffentlich jeder. Das ist keine Frage des richtig oder falsch, sondern der Bedeutung. Inhaltsvergleich bedeutet inhaltliche Gleichheit (das gleiche), Pointervergleich bedeutet Identität (dasselbe). Man muss das machen, was man will.

Du dürftest übrigens vor @synthesize gefühlte 34875638476543874534678 Mal Pointervergleiche vorgenommen haben und dort waren sie auch richtig.

Original von zermelo
Noch einmal zum urspruenglichen Problem:
Wenn ich mich recht erinnere, kann man dem gcc mit einem Flag mitteilen, was fuer ein Typ enums immer haben sollen. Nicht so schoen, aber immerhin.

Typennamen wie "uint8_t" sind uebrigens, wenn ich mich recht erinner, C99 standard, und daher _nicht_ offiziell Teil von C++ und evtl. auch nicht offiziell von Objective-C.

Wenn ich mich recht entsinne, auch nur aus dem holen Buach, kann man die verwendung des C-Standards orthogonal zu Objective-C einstellen.

Original von fwtag

Original von Amin Negm-Awad

Ich bin auch etwas verwundert. Letztlich gibt es da aber keine Garantie. Ich kenne jedenfalls keine. Bei einem extern const habe ich die Garantie, weil ich ja nur eine Definition habe.

Mich wundert das eigentlich nicht:

#define MEINSTRING @"123"

ersetzt doch im Präprozessor MEINSTRING mit @"123" (sic!). Du hast also x-mal @"123" im zu compilierenden Code. Ich fände es schon sehr hoch optimiert vom Compiler, wenn er tatsächlich immer dasselbe Objekt mit dem gleichen Inhalt verwenden würde. Erwarten würde ich, dass immer wieder ein neues Objekt angelegt wird à la [NSString stringWithString:@"123"] (<-- netter Effekt, wenn man mal über @"123" nachdenkt ;-))

Aber wie wir ja schon festgestellt haben: Was ich will geht nicht.

So überraschend ist das nicht, weil der Compiler nur einen Eintrag im TEXT(?)-Segment anlegt, den der Linker zusammenführt. der Linker sieht aber die (nicht) verschiedenen Konstanten und kann das dann optimieren. Ich habe auch schon Tests gemacht und es ging.

Aber wenn man sich nicht darauf verlassen kann …

Original von gritsch
viele wege führen nach rom

youtube.com/watch?v=6O4jLRa1Q98

Ach, noch etwas zu Pointer vs. Inhalt: In Band 2 habe ich so ein ähnliches Problem wie bei Multi-Value-Bindings: Hier gibt es in der Tat keine Garantie für die Identität. Da muss man also -isEqualtToString: verwenden.

Original von fwtag

Original von Amin Negm-Awad

Ich bin auch etwas verwundert. Letztlich gibt es da aber keine Garantie. Ich kenne jedenfalls keine. Bei einem extern const habe ich die Garantie, weil ich ja nur eine Definition habe.

Mich wundert das eigentlich nicht:

#define MEINSTRING @"123"

ersetzt doch im Präprozessor MEINSTRING mit @"123" (sic!). Du hast also x-mal @"123" im zu compilierenden Code. Ich fände es schon sehr hoch optimiert vom Compiler, wenn er tatsächlich immer dasselbe Objekt mit dem gleichen Inhalt verwenden würde. Erwarten würde ich, dass immer wieder ein neues Objekt angelegt wird à la [NSString stringWithString:@"123"] (<-- netter Effekt, wenn man mal über @"123" nachdenkt ;-))

Aber wie wir ja schon festgestellt haben: Was ich will geht nicht.

teusch dich mal nicht!

wenn du 3 mal im code @"123" verwendest bekommst du auch nur eine instanz und nicht 3 verschiedene. Dass du jetzt eine andere bekommst wenn du @"123" in einem weiteren thread verwendest finde ich sehr komisch und glaubs auch nicht bevor ichs nicht getestet habe

Original von gritsch

teusch dich mal nicht!

wenn du 3 mal im code @"123" verwendest bekommst du auch nur eine instanz und nicht 3 verschiedene. Dass du jetzt eine andere bekommst wenn du @"123" in einem weiteren thread verwendest finde ich sehr komisch und glaubs auch nicht bevor ichs nicht getestet habe

Und ich glaube das Gegenteil erst, wenn es spezifiziert ist.

Original von Amin Negm-Awad

Original von zermelo
Noch einmal zum urspruenglichen Problem:
Wenn ich mich recht erinnere, kann man dem gcc mit einem Flag mitteilen, was fuer ein Typ enums immer haben sollen. Nicht so schoen, aber immerhin.

Typennamen wie "uint8_t" sind uebrigens, wenn ich mich recht erinner, C99 standard, und daher _nicht_ offiziell Teil von C++ und evtl. auch nicht offiziell von Objective-C.

Wenn ich mich recht entsinne, auch nur aus dem holen Buach, kann man die verwendung des C-Standards orthogonal zu Objective-C einstellen.

Jain. Ich bin ja C++. C++ ist aelter als C99, darum gehoeren manche Dinge aus C99 einfach nicht zum C++ Standard. So habe ich unter Visual Studio C++ z.B. kein uint8_t, weil es eben nicht zum C++ Std gehoert. (C99 hats wohl im VS auch nicht...naja...Microsoft-Mist). Obj-C ist ja auch aelter, von daher ist evtl. nicht garantiert, dass das so klappt. Auf dem Mac haben wir ja aber die schoenen Header, wo uint8_t etc. definiert ist, da ist man also sowieso auf der sicheren Seite. Aber Standard-konform ist das eher nicht. Du nennst dem gcc ja nur den C Standard fuer C, und nicht fuer Obj-C, oder?

Zum Obj-C String: Hat mir hier nicht neulich jemand erklaert, dass es mir garantiert ist, dass @"xyz" nur ein einziges Mal angelegt wird, egal wie haeufig es im Code verwendet wird?

Original von zermelo
Zum Obj-C String: Hat mir hier nicht neulich jemand erklaert, dass es mir garantiert ist, dass @"xyz" nur ein einziges Mal angelegt wird, egal wie haeufig es im Code verwendet wird?

Nein, man hat es dir erklärt.
Die Aussage hatte aber keinen Bezug auf den gleichen String in unterschiedlichen Threads. Ich habe es so verstanden, als wäre das hier die Diskussionsgrundlage.

Meiner Meinung nach bedeutet anderer Thread = andere Speichernutzung und -zuweisung, und deshalb auch andere Object-IDs für eigentlich gleiche Strings.

Original von Lucas de Vil

Original von zermelo
Zum Obj-C String: Hat mir hier nicht neulich jemand erklaert, dass es mir garantiert ist, dass @"xyz" nur ein einziges Mal angelegt wird, egal wie haeufig es im Code verwendet wird?

Nein, man hat es dir erklärt.
Die Aussage hatte aber keinen Bezug auf den gleichen String in unterschiedlichen Threads. Ich habe es so verstanden, als wäre das hier die Diskussionsgrundlage.

Meiner Meinung nach bedeutet anderer Thread = andere Speichernutzung und -zuweisung, und deshalb auch andere Object-IDs für eigentlich gleiche Strings.

ne, warum das!?

wenn du beim detachen von einem thread objekte mitgibst werden die auch nur retained und nicht kopiert (laut doku)

Warum sollte eine KONSTANTE mehrmals im speicher vorhanden sein (sie kann ja eh nicht geändert werden - was der name ja schon sagt)

Ich kann mir auch nicht vorstellen, dass bei mehren Threads ein anderes Verhalten auftreten kann:

1. Thread sind dennoch in der selben "Speicherwelt", i.e. Speicheraddressen sind zwischen den Threads gleich

2. Gehe ich davon aus, dass der Compiler alle String-Konstanten vorweg in die dafuer vorgesehen Section im Mach-O File ablegt und dann beim Starten entsprechen Instanziiert bzw. an die korrekte Stelle geschoben werden. Wegen 1. muss dem zufolge die Addresse gleich sein.

3. Wegen 2. gehe ich davon aus, dass schon der Compiler alles String-Konstanten zusammen-sammelt. Der Compiler weiss aber noch gar nicht, welche Threads wann worauf zugreifen. Entsprechend kann er gar nicht mehrere Instanzen "planen".

Ist jetzt aber nur geraten, von dem, was ich hier gehoert habe, und von dem, wass ich ueber Mach-O/Obj-C mal wusste

Original von zermelo

Original von Amin Negm-Awad

Original von zermelo
Noch einmal zum urspruenglichen Problem:
Wenn ich mich recht erinnere, kann man dem gcc mit einem Flag mitteilen, was fuer ein Typ enums immer haben sollen. Nicht so schoen, aber immerhin.

Typennamen wie "uint8_t" sind uebrigens, wenn ich mich recht erinner, C99 standard, und daher _nicht_ offiziell Teil von C++ und evtl. auch nicht offiziell von Objective-C.

Wenn ich mich recht entsinne, auch nur aus dem holen Buach, kann man die verwendung des C-Standards orthogonal zu Objective-C einstellen.

Jain. Ich bin ja C++. C++ ist aelter als C99, darum gehoeren manche Dinge aus C99 einfach nicht zum C++ Standard. So habe ich unter Visual Studio C++ z.B. kein uint8_t, weil es eben nicht zum C++ Std gehoert. (C99 hats wohl im VS auch nicht...naja...Microsoft-Mist). Obj-C ist ja auch aelter, von daher ist evtl. nicht garantiert, dass das so klappt. Auf dem Mac haben wir ja aber die schoenen Header, wo uint8_t etc. definiert ist, da ist man also sowieso auf der sicheren Seite. Aber Standard-konform ist das eher nicht. Du nennst dem gcc ja nur den C Standard fuer C, und nicht fuer Obj-C, oder?

Ich meinte ja nur den zweiten Teil (Objective-C). Vr Ewigkeiten habe ich das mal ausprobiert und ich setzte ihm auch den Standard für Objective-C. Es ging um for( int a = 0; …). Keine Ahnung, in welchem Standard das geht und in welchem nicht. Aber damals ging es jedenfalls nach Änderung des Standards.

Original von Amin Negm-Awad

Original von zermelo

Original von Amin Negm-Awad

Original von zermelo
Noch einmal zum urspruenglichen Problem:
Wenn ich mich recht erinnere, kann man dem gcc mit einem Flag mitteilen, was fuer ein Typ enums immer haben sollen. Nicht so schoen, aber immerhin.

Typennamen wie "uint8_t" sind uebrigens, wenn ich mich recht erinner, C99 standard, und daher _nicht_ offiziell Teil von C++ und evtl. auch nicht offiziell von Objective-C.

Wenn ich mich recht entsinne, auch nur aus dem holen Buach, kann man die verwendung des C-Standards orthogonal zu Objective-C einstellen.

Jain. Ich bin ja C++. C++ ist aelter als C99, darum gehoeren manche Dinge aus C99 einfach nicht zum C++ Standard. So habe ich unter Visual Studio C++ z.B. kein uint8_t, weil es eben nicht zum C++ Std gehoert. (C99 hats wohl im VS auch nicht...naja...Microsoft-Mist). Obj-C ist ja auch aelter, von daher ist evtl. nicht garantiert, dass das so klappt. Auf dem Mac haben wir ja aber die schoenen Header, wo uint8_t etc. definiert ist, da ist man also sowieso auf der sicheren Seite. Aber Standard-konform ist das eher nicht. Du nennst dem gcc ja nur den C Standard fuer C, und nicht fuer Obj-C, oder?

Ich meinte ja nur den zweiten Teil (Objective-C). Vr Ewigkeiten habe ich das mal ausprobiert und ich setzte ihm auch den Standard für Objective-C. Es ging um for( int a = 0; …). Keine Ahnung, in welchem Standard das geht und in welchem nicht. Aber damals ging es jedenfalls nach Änderung des Standards.

in C99 gehts - ich verwende immer den C99-dialect