Hallo zusammen

Ich habe nun eine Weile mit C++ verbracht und würde von mir selbst behaupten, die Sprache einigermassen zu beherschen. Ich stehe nun vor der Entscheidung, für ein Uniprojekt mit OpenGL entweder C++ oder Objective-C zu verwenden. Programmiert wird in XCode ein App für das iPad. Dabei wird uns ein Framework zur Verfügung gestellt, welches in C++ weitergeführt würde. Da ich dem Framework aufgrund Ausführungen der Teaching Assistants nicht unbedingt vertraue, haben wir nach einem Framework ähnlicher Art gesucht und auch gefunden, allerdings verlangt dieses Objective-C. Wie ich gehört habe, sind die Unterschiede nicht allzu gross, deshalb wollte ich Wissende fragen, wie denn genau die Unterschiede zwischen C++ und Obj-C sind?

Gegoogelt habe ich das ganze bereits, Resultate habe ich auch gefunden, jedoch waren diese zu wenig ausführlich... Darum bin ich um euer Wissen sehr froh.

Danke für eure Hilfe

Ähm, die Syntax und das Framework? Statt der Bibliothek arbeitest Du ja mit Obj. C mit Cocoa Touch und verbringst die meiste Zeit in der Doku dazu. Ansonsten liegt bei beiden ja C drunter, das man bei Obj. C öfter nutzt (oder kann). Das neue Automatic Reference Counting und die Nachrichten in Obj. C sind natürlich super cool.

Das war jetzt vielleicht nicht so hilfreich, aber ich weiss nicht worauf Du Wert legst.

Das ganze bezog sich eher auf die Syntax. Danke für deine Einschätzungen! Das mit dem Message-System habe ich bereits gelesen, scheint wirklich eine tolle Sache zu sein!

Objective C und C++ haben nicht ganz so viel gemeinsam, wie man denken möchte. C++11 ist eine sehr mächtige Sprache, mit der sich viele Dinge elegant ausdrücken lassen. Ältere ausgaben von C++ machen einiges umständlicher und schwerer lesbar, aber grob betrachtet fallen die Unterschiede oft nicht einmal auf.

Objective C ist eine überschaubarere Sprache. Die reine Syntax ist schnell erklärt (wenn man C schon kann) aber die Nutzung in den Frameworks ist sehr clever und hat viele Konventionen, die man richtig anwenden muss. Ausserdem hat Cocoa die Tendenz zu leicht umständlichen Methodennamen [foo initWithCoder: bar byAlgorithm: sort forClient: self].

Umgekehrt gibt es einige Programmierregeln in C++ die in Objektive C keinen Sinn machen würden, weil Obj C viel dynamischer ist und weniger stark auf Compiler-Time-Features zurückgreift.
Das Command-Pattern und "Ressource aquisition is initialization" sind einige Beispiele für Konzepte, die in Objektive C keinen Vorteil bringen.
Gestandene C++-Programmierer haben oft Probleme sich umzugewöhnen. Beispielsweise ist die Idee, dass Methodenaufrufe einfach verpuffen können ist einigen unheimlich (sending messages to NIL, etc...).

Cocoa Programmierer finden C++ tendenziell umständlich, inkonsequent und voller Features mit zweifelhaftem Mehrwert. Es dauert länger eine korrekte C++-Klasse zu implementieren als ihr ObjC Gegenstück. Dafür kann man ggF. einiges an RAM und Taktzyklen mit C++ sparen, die als overhead von der Cocoa Runtime immer dabei sind.

Meine C++ Kenntnisse reichen leider für einen direkten Vergleich nicht aus. Von der Java Seite her würde ich aber noch die @property im Header File mit @synthesize in der Implementation hervorheben, damit erspart man sich das implemtieren der Getter/Setter. Wichtig ist auch das Obj. C einem dazu zwingt Design Patterns zu nutzen, wo man sich mit C++ drumrummogeln kann. Weiter mag ich mich aber nicht aus dem Fenster lehnen.

Wahrscheinlich wird man aber sowie in einem Apple Forum eh nur Werbung für Obj. C erhalten

@Bitnacht: Message to nil? Ohhhh ja, das ist freakig. Hat mich einiges an Lebenszeit gekostet

Wenn Du auf dem Gerät eine GUI erzeugen willst - was Du eigentlich musst (auf dem iPad gibt es ja keine Konsolen-Apps ), dann kommst Du um ObjC und Cocoa doch gar nicht herum. Denn alle für die Benutzung von iOS nötigen APIs Verlagen ObjC.

Das ist aber auch gar nicht schlimm, Du kannst ja problemlos in einem Projekt ObjC mit C++ mischen.
Sodass die Cocoa GUI mit ObjC gemacht ist und die App dann dein Framework in C++ aufruft.

Und bezüglich der Syntax sieht es ungefähr so aus:

Nehmen wir mal an, Du hast eine Klasse Rechner die im Konstruktor zwei Werte (a und b) erhält und die summe davon berechnen kann. Jeweils in C++ und ObjC. Dann sieht die Benutzung der Klasse so aus in C++:


... und in ObjC;


Nun hast Du ungefähr einen Eindruck, was Dir "blüht"... aber keine Angst, die ObjC Syntax ist intuitiver als sie aussieht und nach 2 Wochen denkst Du nicht mehr darüber nach.

Stichwort "freakig": Es gibt in C++ etwas was mich einiges an Haaren gekostet hat: wenn man einen Konstruktor mit genau einem Parameter hat und nicht "explicit" davor schreibt, dann wird dieser automatisch und "unsichtbar" aufgerufen, um in einem (anderen) Funktionsaufruf eine Typkonversion vorzunehmen:

Klasse a - Konstruktor nimmt Parameter Klasse b

Funktion nimmt Parameter Klasse a.

Aufruf der Funktion (versehentlich) mit Parameter vom Typ b.

Ein neues Objekt der Klasse a wird mit dem Konstruktor auf dem Stack erzeugt und nach Aufruf der Funktion gelöscht.

Als Folge hab ich zwei Jahre lang "explicit" für das wichtigste Schlüsselwort in C++ gehalten. Danach hatte ich mich beruhigt

Ja, das ist in C++ schon manchmal haarig: man muss schon ziemlich genau wissen, was eine Kasse alles zur Verfügung stellt, um die tatsächlichen impliziten Aufrufe zu kennen.
Ist das in Obj-C anders?

Nein, in C++ würde man das eben nicht so machen.

Hallo? Das war ein simpel Beispiel ohne Anspruch auf Sinnvolligkeit. Es ging mir darum ein Beispiel für die Sytaxunterschiede zwischen C++ und ObjC irgendwie darzustellen.

Ja. Natürlich gibt es durch Vererbung , das Delegate-Konzept und Protokolle Situationen, wo ein Aufruf nach weniger aussieht, als er ist, aber das ist etwas anderes.

Objective C unterstützt auch nicht das Überladen von Funktionen anhand der Parametertypen. Deswegen heißen dann Methoden "initWithInteger" und "initWithString". Das ist zwar mehr Schreibarbeit, aber der generischen Programmierung schadet es kaum. Man behält so aber umgekehrt auch ganz gut den Überblick.

Nur so würde man dieses Codebeispiel in C++ nie formulieren. Entweder so
oder so

Die ISO Variante mit shared_ptr spare ich gerade mal aus, dazu müßte ich erstmal die ISO Norm anschauen.

@gfhfkgfhfk & ExMacRabbitPro:

Schönes simple Beispiele für ObjC und C++
Irgendwie bestätigt das mein Vorurteil, dass C++ irgendwie "komisch riecht" und der Code nicht sehr angenehm lesbar ist

Davon ab würde ich das Beispiel so schreiben:

Und da kommen die Nettigkeiten von ObjC hervor:
Der Methodennamen [r1 summeAus: mit:]: spricht für sich selbst.
Peter

Es ist so eine Foren-Unart, dass gewisse Leute gerne die Energie aufwenden die Antworten anderer Leute zu kritisieren aber dagegen seltenst aus freien Stücken direkt etwas zum Thema beitragen...

Amen!

Sollte ich mich angesprochen fühlen

Peter

Nein

Danke für die vielen konstruktiven Antworten . Mir ist bewusst das ich sehr wohl Obj-C mit C++ vermischen muss, aber es ist auch möglich ein GUI ohne Obj-C zu schreiben (Mit OpenGL und Texture-Mapping kann man da sehr viel machen). Da es ein 3D-Game wird bietet sich diese Variante so oder so an.
Einziges Problem dabei ist, dass das App sobald gestartet sämtliche Objekte zuerst laden muss, was beim iPad ein leerbleibender, schwarzer Bildschirm bedeutet .

Natürlich kannst Du mit OpenGL deine gesamte GUI selbst machen. Das tun auch alle Game Engines. Einzig ein minimales Grundgerüst der App in ObjC und Cocoa benötigst Du, um einen OpenGL View zu etablieren. Von da an ist es dann dir überlassen was du machst.

Was den Ladevorgang angeht, so ist es natürlich kein gutes Application-Design einen schwarzen Bildschirm zu zeigen und erst alle Objekte zu laden. Unter iOS muss eine App auch innerhalb von 2 Sekunden (oder waren es 5? weiss nicht mehr) einen initialen View dem User angezeigt haben, sonst wird die App vom System beendet.

Aber es ist normalerweise kein Problem, diesen View als Ladefortschrittsanzeige zu realisieren und im Hintergrund alle notwendigen Dinge zu laden. So sieht der User auch, dass sich etwas tut.

Klar, so wird das auch geschehen . Ich werde wahrscheinlich bei C++ bleiben und mir die nötigen Elemente für Obj-C heraussuchen.

Auch wenn etwas gut gemeint ist, ist es nicht automatisch gut. Wenn man also Programmbeispiele bringt, sollte dieses nicht aus der Mottenkiste heraus geholt werden. Wenn man die Unterschiede zwischen zwei Programmiersprache aufzeigen will, dann sollte man in der Lage sein die unterschiedlichen Konzepte wiedergeben zu können. Wenn man in einem Programmbeispiel für C++ RAII nicht verwendet - wird es nun einmal peinlich. Dazu ist dieses Konzept viel zu lange im Umfeld etabliert und akzeptiert.Es ist einen Forenunart, daß auf Kritik Personen immer wieder mit persönlichen Angriffen reagieren.