Ist ein Interface/Klasse zugleich auch ein Struct?

Scharnagl · 13. Juni 2007, 23:28

Umfasst eine Objective-C Klasse (Interface) zugleich auch die Eigenschaften und Möglichkeiten eines herkömmlichen C-structs? Wenn nein, wo sind die Einschränkungen?

Christian Kienle · 13. Juni 2007, 23:33

Es würde den Gedankenaustausch ungemein erleichtern, falls du in deinen Posts von Anfang an etwas konkreter wirst.

Welche großen Eigenschaften und Möglichkeiten hat ein C Struct denn? Das ist doch dumm wie ein Stück Brot... oder?

Scharnagl · 13. Juni 2007, 23:44

Original von Objcler
... Das ist doch dumm wie ein Stück Brot... oder? ...

Na ja, z.B. in C++ sind Klassen formal zugleich auch (besondere) Structs.

Jemand der in Objective-C zu Hause ist, sollte die Frage, ob ein Interface zugleich auch ein struct im Sinne von C ist, mit "ja" oder "nein" beantworten können. Leider vermochte ich diese Fragestellung als Newcomer in Objective-C selber nicht zu lösen, deshalb fragte ich eben hier.

Könnte ich diese Frage noch weiter präzisieren, bräuchte ich sie wahrscheinlich gar nicht erst zu stellen.

Christian Kienle · 13. Juni 2007, 23:50

Ja siehste. Ich wusste nicht, dass du dich in deiner Frage auf die Möglichkeit das Schlüsselwort "class" durch das Schlüsselwort "struct" auszutauschen beziehst. Das Austauschen des Schlüsselwortest bei der Definition einer Klasse hat doch nur auf die Defaultsichtbarkeit der membervariablen Einfluss - oder?

In Objective-C kannst du das nicht beeinflussen.

Christian Kienle · 13. Juni 2007, 23:54

Wobei eine Klasse in Objective-C im Objective-C Runtimekontext als Struct definiert ist.

longW · 13. Juni 2007, 23:55

in objc/objc.h:

Quellcode

typedef struct objc_object {
Class isa;
} *id;

sieht das so aus.

Scharnagl · 13. Juni 2007, 23:59

Original von Objcler
... doch nur auf die Defaultsichtbarkeit der membervariablen Einfluss - oder? ...

Weit gefehlt. Ein struct erlaubt ja auch noch andere Dinge wie etwa Methoden, die ja auch inline sein dürfen.
Sie wären in Objective-C Interfaces - sofern diese auch zugleich Structs wären - eben keine Message-getriebenen Methoden, sondern traditionelle Funktionsaufrufe.

Um diese in structs vorhandenen Möglichkeiten geht es mir.

Graboid · 14. Juni 2007, 00:41

inline methoden in Objective-C Klassen gibt es nicht.

Eine Klasse in Objective-C unterscheidet sich aufgrund der hohen Dynamik von einem simplem C struct weit aus mehr als eine C++ Klasse sich von einem C struct unterscheidet.

Darum würde ich deine Frage mit "nein" beantworten. Auch wenn intern aus jeder Objective-C Klasse ein C Struktur generiert wird, die haufenweise weitere structs beinhaltet, die die Dynamik ermoeglichen.

Aber prinzipiell spricht in ObjC ja nichts dagegen auch mal eine C Struktur statt einer ObjC Klasse zu verwenden, wenn dir die Eigenschaften wichtiger sind.

Scharnagl · 14. Juni 2007, 01:30

Original von Graboid
..., wenn dir die Eigenschaften wichtiger sind.

Mir geht es nicht im die Priorisierung deren Eigenschaften, sondern um das Wissen darüber, damit ich bei passender Gelegenheit von der entsprechendsten Gebrauch machen kann.

Amin Negm-Awad · 14. Juni 2007, 09:23

Nein, in Objective-C sind OO-Teile und Plain-Teile strikt getrennt.

Da aber alles im Hauptspeicher eine Anordnung von Bytes ist und du mit Structs eine Anordnung von Bytes halbwegs compiler- und CPU-abhängig anlegen kannst, kannst du eine Struct darüber legen.

Nein, das ist nicht sinnvoll.

Ansonsten wird – wie von Grabold bereits ausgeführt – intern natürlich eine Struct zur Laufzeit verwendet.

ssb · 14. Juni 2007, 09:58

Prinzipiell ist es schon so, dass eine Klasse intern ein Struct ist. Die Struct enthält dann natürlich auch die Zeiger auf die Methoden und so weiter. Der Grund ist ganz einfach: C++ und ObjC werden vom Compiler erstmal in C-Code übersetzt und dann kompiliert - das geht inzwischen aber in einem Schritt - früher (zu MPW Zeiten) wurde tatsächlich erst C++ -> C -> Asm übersetzt - aber da gab es auch noch 2-Pass C Compiler.

Ich habe mich auch schon mit der Structur von ObjC Klassen beschäftigt und hatte mal ein kleines Tool gebaut, dass das "__OBJC" Segment in einem Programm analysiert - ihr glaubt gar nicht, was da alles drinsteht. Natürlich habe ich diesen Code in C geschrieben, und das kennt eben nur Structs...

Übrigens kann man ObjC ja auch ohne die ObjC-Syntax, also in C-Syntax, benutzen, das sieht nur ein wenig hässlich aus...

Amin Negm-Awad · 14. Juni 2007, 10:32

Übrigens kann man ObjC ja auch ohne die ObjC-Syntax, also in C-Syntax, benutzen, das sieht nur ein wenig hässlich aus...

Und ist auch etwas mühselig.

An einem Punkt möchte ich aber einhaken, da er sonst möglicherweise auf den Gedanken kommt, der Objective-C-Code "an sich" würde in C umgewandelt. Anders als in C++ gibt es eine sehr umfangreiche RTE. Es wird also sozusagen in C-Funktionen umgewandelt, die die RTE aufrufen.

Das scheint mir bei der praktischen Low-Level-Arbeit einen Unterschied zu machen.

Scharnagl · 14. Juni 2007, 18:23

Möglicherweise hat ein im anderen Thread gewunkener Zaunpfahl es schon signalisiert: ich beschäftige mich in dieser Phase vielleicht zu sehr mit abstrakten Überlegungen, statt einfach einiges spontan auszutesten. Aber so bin ich nun mal, und das Ausprobieren kommt ganz sicher auch noch ausgiebig dran.

Ein Aspekt, den eine Klasse für mich auch noch hat, ist der einer Klammerung verwandter Funktionalitäten. In C++ ist das eben mittels eines Satzes statischer Funktionen möglich, was erstmal keinerlei Geschwindigkeitseinbußen mit sich bringt. Ich verwende dies deshalb sehr häufig.

Mir scheint es in Objective-C jedoch eher abwegig, allein aus diesem genannten Grund eine Klasse zu erstellen, da neben der Kapselung eben auch eine lokale Nachrichtenverarbeitung begründet wird, die in solchem Kontext eigentlich nicht unbedingt von mir gewollt ist.

Vielleicht gibt es in Objective-C hierzu aber Alternativen, die mir nur noch nicht begegnet sind.

Amin Negm-Awad · 14. Juni 2007, 19:51

Entsprechendes wären in Objective-C Klassenmethoden. Aber es gibt da zwei wesentliche Unterschiede, die natürlich zusammenhängen:

a) Wie du ganz richtig sagst, ändert das erst einmal grundsätzlich nichts am Dispatching.
b) Daraus resultiert, dass diese Methoden auch polymorph sind.

Für das, was du vorhast benötigst du es aber gerade nicht, wobei ich nicht ganz verstehe, warum du eine semantische Kapselung benötigst, also über Dateien hinaus. Du kannst das ganze natürlich einfach in eine Struct von Funktionszeiger stopfen, die du global instantierst und initialisierst und hast dann im Ergebnis dasselbe. Wenn man's schön findet …