Objective C und C++ mixen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • zerm schrieb:


    im prinzip mein ich sowas:
    ideone.com/PhbTWP

    ist ein wenig wichtiger bei freien Funktionen wie "begin(T)", von denen man häufig std::begin will, aber nicht ausschliessen will, das für einen non-std::-Typ der Nutzer auch ein begin bereitstellt.


    Danke für das Beispiel. Irgendwie kommt es mir komisch vor, dass man Sourcecode weiterverwenden will, aber nicht das Kompilat in der Art einer Library. Hat für mich immer etwas von Copy&Paste, aber das ist wohl C++...
  • Wenn ich eine generische Funktion (oder Methode) erstellen will, die mit verschiedensten Typen funktioniert, ist das Copy&Paste? Ja, in Objective-C kann man für so eine "doit" Funktion einfach ein "id" Parameter annehmen, und an diesen blind ein "print" senden. In C++ arbeitet man halt anders, was ich persönlich sogar vorziehe.
    C++
  • zerm schrieb:


    Wenn ich eine generische Funktion (oder Methode) erstellen will, die mit verschiedensten Typen funktioniert, ist das Copy&Paste?


    Wenn du den Quellcode verändern musst, ja. Und du musst den Quellcode verändern, weil dein Source sonst die neuen Typen, mit denen er funktionieren soll, nicht kennt - auch wenn es nur heißt mehr Header zu inkludieren, es ist eine Codeänderung und Neukompilation - den bestehenden Code kannst du nicht wiederverwenden, zum Beispiel in einer Bibliothek.

    zerm schrieb:


    Ja, in Objective-C kann man für so eine "doit" Funktion einfach ein "id" Parameter annehmen, und an diesen blind ein "print" senden.


    Ich kenne das konkrete Problem ja nicht, aber Protokolle helfen, wenn es etwas typsicherer sein soll.

    zerm schrieb:


    In C++ arbeitet man halt anders, was ich persönlich sogar vorziehe.


    Jetzt habe ich wieder diese Pro-Contra-Diskussion angefangen, wollte ich nicht. Ich finde nur ADL ein seltsames Feature, weil es die Wiederverwendbarkeit von Code einschränkt. Man löst so ein Problem ja eigentlich mit Dependency Inversion, was ja auch in C++ prima geht - das ursprünglich GoF-Buch bezieht sich ja auf C++.

    Nur bevorzugen im modernen C++ manche den selben Code für jeden Typ extra zu kompilieren und verkaufen das als Vorteil. Verstehe ich nicht.
  • SteveJ schrieb:

    Wenn du den Quellcode verändern musst, ja. Und du musst den Quellcode verändern, weil dein Source sonst die neuen Typen, mit denen er funktionieren soll, nicht kennt - auch wenn es nur heißt mehr Header zu inkludieren, es ist eine Codeänderung und Neukompilation - den bestehenden Code kannst du nicht wiederverwenden, zum Beispiel in einer Bibliothek.

    Ist ein eingeschränkt sinvolles Beispiel gewesen. Für nicht-primitiv-typen muss ich nichts anfassen, und ADL kümmert sich um den korrekten Namespace. Hier habe ich das ganze um einen neuen Typ erweitert: ideone.com/xACUpY -- "using" ist eher als "Fallback" gedacht; eben auch, damit man Quellcode genau nicht ändern braucht.
    C++
  • zerm schrieb:


    Für nicht-primitiv-typen muss ich nichts anfassen, und ADL kümmert sich um den korrekten Namespace. Hier habe ich das ganze um einen neuen Typ erweitert: ideone.com/xACUpY


    Genau in diesem Beispiel fasst du den Code an. ADL verschleiert die Änderung, so dass du den Effekt nicht an der Stelle der eigentlichen Wirkung siehst, aber deine Änderungen erzeugen neuen kompilierten Code, den es vorher nicht gab - eine neue, spezialisierte doit-Funktion.

    zerm schrieb:


    -- "using" ist eher als "Fallback" gedacht; eben auch, damit man Quellcode genau nicht ändern braucht.


    Du musst dem Code irgendwie den neuen Typ bekannt machen, damit änderst du ihn. Die Tatsache das du innerhalb der doit-Funktion kein Zeichen änderst heißt nicht, das nicht neuer Code im Kompilat nötig wäre - als Bibliothek taugt so etwas nicht.

    Das heißt du kannst keine Library schreiben die wiederverwendbar wäre, sondern musst deinen Code für jeden neuen Typ erneut kompilieren - das ist für mich Copy&Paste, auch wenn es ein sehr elegantes und einfaches Copy&Paste ist. Mit Dependency Inversion hättest du weniger, wiederverwendbaren Code - warum machst du dir das kaputt? Was ist der Vorteil?
  • Das kommt immer darauf an, was man machen möchte. Viele Dinge gehen mit Templates sehr elegant (Details mag ich jetzt dazu aber nicht diskutieren). Das ganze funktioniert natürlich nicht mit kompilierten Libraries - muss es auch nicht. Zudem hat man "Header-Libraries", wie etwa grosse Teile von boost. An den Stellen, wo ich solche Dinge verwende, ist es in der Regel ohnehin nicht sinnvoll, eine eigene (binär) Library zu erstellen. Und auf höherer Abstraktionsebene kann man natürlich immernoch entsprechende Techniken anwenden.
    C++
  • Erst einmal vielen Dank an SteveJ, dass er diesmal die Diskussion führt. *g*

    Im Grunde genommen läuft das doch jedes Mal gleich: Der eigentliche Unterschied ist schon im ersten Beitrag enthalten und alles Folgende sind nur noch Schattierungen. Für C++ ist nun einmal Typsicherheit eine Frage der Übersetzungszeit und daraus folgt Generizität. (Was hinsichtlich erst jetzt eingeführter Interfaces, äh, Concepts, zu einer Verschlechterung der Typsicherheit führt.) Für Objective-C ist das eine Frage der Laufzeit und daraus folgt Objektorientierung. Und alles andere einschließlich kryptischer Header und Pflicht zur Lieferung von Sourcen ist doch nur die Konsequenz daraus.

    Man mag es ja elegant finden, dass ich eine Addition zweier Objekte mit Infixnotation schreiben kann. Wenn ich allerdings bedenke, was daraus als Rattenschwanz folgt einschließlich ADL, einschließlich unterschiedlicher Implementierungen von ADL, einschließlich letztlich eines hilflosen Standards (war das nicht eine der Stärken von C++?) ist es einfach ein Minimum an Vorteil, welcher mit einem riesigen Gebäude an Folgefragen, Folgefehlern, Folgeproblemen erkaufe. Da schreibe ich doch lieber weiterhin [string appendString:…] anstelle von irgendwas mit + und der anschließenden Frage, ob das überhaupt sinnvoll ist - um dann wegen der leichten Lesbarkeit nicht zu wissen, was mein Compiler eigentlich daraus macht. Obfuscated-Lesbarkeit.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?