C++ Bibliotheken im Umfang wie Java?



  • Sebastian Pizer schrieb:

    Aber die neuen "core language" Features kommen gerade Bibliotheksentwicklern sehr entgegen. Wenn man sie nicht direkt benutzt, benutzt man sie eben indirekt über Bibliotheken. Das musste ich jetzt doch nochmal betonen. 😉

    Und wenns dann noch ein einheitliches Name-Mangling gäbe....

    SCNR 😉

    Stefan.



  • Sebastian Pizer schrieb:

    Aber die neuen "core language" Features kommen gerade Bibliotheksentwicklern sehr entgegen. Wenn man sie nicht direkt benutzt, benutzt man sie eben indirekt über Bibliotheken. Das musste ich jetzt doch nochmal betonen.

    Gut, aber bestehende Bibliotheken, die schon einen gewissen Reifegrad erreicht haben, werden wohl kaum wegen der neuen Sprachmitteel umdesigned werden. 😉



  • general bacardi schrieb:

    Gut, aber bestehende Bibliotheken, die schon einen gewissen Reifegrad erreicht haben, werden wohl kaum wegen der neuen Sprachmitteel umdesigned werden. 😉

    Doch warum nicht? Auch wenn Bibliotheken schon den "gewissen Reifegrad" haben kann man sie durch die neuen Sprachmittel durchaus noch weiter reifen lassen.



  • DStefan schrieb:

    Und wenns dann noch ein einheitliches Name-Mangling gäbe....

    Das bringt Dir eigentlich gar nichts. Es schadet sogar eher. Mit unterschiedlichen Nane-Manglings weist Dich wenigstens der Linker darauf hin, dass da etwas nicht stimmt. Ist das Name-Mangling gleich, ist der Linker zufriedengestellt. Funktionieren muss das Programm trotzdem nicht, weil die ABI immernoch unterschiedlich sein kann (vtables, parameterübergabe, ...). Es kann also sein, dass Du Dein Programm kompiliert und geladen bekommst, es aber trotzdem abstürzt. Unterschiedliches Name-Mangling ist also eher ein Feature, was Dir die Früherkennung von Fehlern erlaubt.



  • pumuckl schrieb:

    general bacardi schrieb:

    Gut, aber bestehende Bibliotheken, die schon einen gewissen Reifegrad erreicht haben, werden wohl kaum wegen der neuen Sprachmitteel umdesigned werden. 😉

    Doch warum nicht? Auch wenn Bibliotheken schon den "gewissen Reifegrad" haben kann man sie durch die neuen Sprachmittel durchaus noch weiter reifen lassen.

    Man kann neue Funktionen unter Verwendung der Neuen Sprachemittel hinzufügen. Das ist kein Problem, nur sollte man bestehenden und funktionierenden Code nicht aus dem Grund ändern, weil es neue Sprachmittel gibt. Die Gefahr ist zu groß, dass dadurch Fehler eingebaut werden, wo vorher keine waren. :p



  • general bacardi schrieb:

    Man kann neue Funktionen unter Verwendung der Neuen Sprachemittel hinzufügen. Das ist kein Problem, nur sollte man bestehenden und funktionierenden Code nicht aus dem Grund ändern, weil es neue Sprachmittel gibt. Die Gefahr ist zu groß, dass dadurch Fehler eingebaut werden, wo vorher keine waren. :p

    Wieso nicht? Wenn zum Beispiel die Performance durch RValue-Referenzen verbessert werden kann oder man sich Präprozessormetaprogrammierung und etliche Funktionsüberladungen durch Variadic Templates erspart, ist das doch ein guter Grund für eine Änderung, oder nicht?



  • Nexus schrieb:

    general bacardi schrieb:

    Man kann neue Funktionen unter Verwendung der Neuen Sprachemittel hinzufügen. Das ist kein Problem, nur sollte man bestehenden und funktionierenden Code nicht aus dem Grund ändern, weil es neue Sprachmittel gibt. Die Gefahr ist zu groß, dass dadurch Fehler eingebaut werden, wo vorher keine waren. :p

    Wieso nicht? Wenn zum Beispiel die Performance durch RValue-Referenzen verbessert werden kann oder man sich Präprozessormetaprogrammierung und etliche Funktionsüberladungen durch Variadic Templates erspart, ist das doch ein guter Grund für eine Änderung, oder nicht?

    Ja, wenn es einen signifikanten Vorteil bringt. Eine Änderung muss sich lohnen, um die Gefahr neuer Bugs auf sich zu nehmen. Nur die Geschwindigkeit zu verbessern obwohl vorher schon alles schnell genug war, ist kein Grund. Nagut, man könnte seine Bibliothek dann mit verbesserten Leistungsdaten gegenüber der Konkurrenz bewerben, was auch ein suareichender Grund sein könnte.



  • Sebastian Pizer schrieb:

    DStefan schrieb:

    Und wenns dann noch ein einheitliches Name-Mangling gäbe....

    Das bringt Dir eigentlich gar nichts. Es schadet sogar eher. Mit unterschiedlichen Nane-Manglings weist Dich wenigstens der Linker darauf hin, dass da etwas nicht stimmt. Ist das Name-Mangling gleich, ist der Linker zufriedengestellt. Funktionieren muss das Programm trotzdem nicht, weil die ABI immernoch unterschiedlich sein kann (vtables, parameterübergabe, ...). Es kann also sein, dass Du Dein Programm kompiliert und geladen bekommst, es aber trotzdem abstürzt. Unterschiedliches Name-Mangling ist also eher ein Feature, was Dir die Früherkennung von Fehlern erlaubt.

    Hmmmm - ich seh schon, ich bin zu kurzsichtig. Trotzdem, finde ich, ist an der ganzen Sache was dran. C++-DLLs einfach verwenden zu können ohne Rücksicht auf Hersteller oder Version des Compilers... Find ich erstrebenswert.

    Stefan.



  • DStefan schrieb:

    Hmmmm - ich seh schon, ich bin zu kurzsichtig. Trotzdem, finde ich, ist an der ganzen Sache was dran. C++-DLLs einfach verwenden zu können ohne Rücksicht auf Hersteller oder Version des Compilers... Find ich erstrebenswert.

    Dazu ist C++ im Prinzip zu systemnah. Das hat don Vorteil, dass man verschiedene Eigenschaften des Systems nutzen kann, um performanteren Code zu erstellen, und verschiedene Compiler nutzen eben verschiedene Optimierungsmöglichkeiten. Wenn du die DLLs derart standardisieren würdest, müssten viele dieser Optimierungen wegfallen, weil die Compiler durch die Restriktionen eben in ihren Möglichkeiten eingeschränkt würden. Das ist eben der Nachteil an der Systemnähe.



  • DStefan schrieb:

    Trotzdem, finde ich, ist an der ganzen Sache was dran. C++-DLLs einfach verwenden zu können ohne Rücksicht auf Hersteller oder Version des Compilers... Find ich erstrebenswert.

    Das funktioniert dann, wenn es für die Plattform eine ABI gibt, an die sich die Compilerhersteller halten. Die ABIs über alle möglichen Plattformen zu standardisieren ist aber nicht Aufgabe des C++ Standardisierungskomitees -- kann es auch nicht sein. Es gab, so wie ich das verstanden habe, das Bestreben die ABI für die Intel 64Bit-Plattform zu "standardisieren" (Quasi-Standard). Ich habe das aber nicht so richtig verfolgt.

    Gruß,
    SP


Anmelden zum Antworten