welche vorteile bietet c++ gegenüber c
-
Wenn du geschrieben hättest "Ich kenne nichts [in C++] was auch nur annaehernd so gut ist", dann würde ich zustimmen.. ich bin nur vom Gesamtkonzept an der Stelle nicht übermäßig begeistert.
Wie würdest du es denn gerne gelöst wissen? Oder in welcher Sprache hat man bessere Werkzeuge, die solche (seltenen) Probleme lösen (Garbage Collection hat natürlich die gleichen Probleme, nur das sie nicht auftreten, wenn es der Programmierer will, sondern wenn der GC meint das Objekt zerstören zu können).
-
GPC schrieb:
Wenn du geschrieben hättest "Ich kenne nichts [in C++] was auch nur annaehernd so gut ist", dann würde ich zustimmen.. ich bin nur vom Gesamtkonzept an der Stelle nicht übermäßig begeistert.
Ich kenne keine Sprache wo ich mich nicht immer mal wieder nach RAII sehne.
Kein Konzept dass ich kenne kommt an RAII ran. Welche Sprache bzw. welche Konzepte würdest du besser finden?
-
Irgendwer schrieb:
Wie würdest du es denn gerne gelöst wissen? Oder in welcher Sprache hat man bessere Werkzeuge, die solche (seltenen) Probleme lösen (Garbage Collection hat natürlich die gleichen Probleme, nur das sie nicht auftreten, wenn es der Programmierer will, sondern wenn der GC meint das Objekt zerstören zu können).
Ja, würd mich auch interessieren in welcher Sprache du das besser gelöst siehst.
Garbage Collection ist jedenfalls keine Lösung, im Gegenteil. Zwar brauchst du dich dort um Speicher nichtmehr zu kümmern aber alles andere wird ungemein umständlicher. Darum braucht man dann in C# und Java so Zeug wie finally Blöcke und den Dispose Pattern. Beides ist, wenn du mich fragst, RAII weit unterlegen. Ich mag C#, aber trotzdem wünsch ich mir dort sehr oft ich könnte RAII verwenden...
-
Ein GC hat ja auch das Problem. Nehmen wir an, aus irgendeinem Grund könnte das Freigeben von Speicher fehlschlagen. Banalere Variante: der Finalizer eines Objekts wirft eine Exception.
Zumindest beim Java-GC wird diese einfach ignoriert...
-
Um die letzten vier Posts also zusammenzufassen:
- RAII ist nicht perfekt, aber am Besten. Was schlägst Du Besseres vor?
- Um Dir das Argument vorwegzunehmen: GC bringt auch nix.
-
dot schrieb:
Ich mag C#, aber trotzdem wünsch ich mir dort sehr oft ich könnte RAII verwenden...
Du hast in C# using() Blöcke. Die helfen oft. Python bietet das auch an (with). Ist ganz OK, halt eine light Variante von RAII.
-
Shade Of Mine schrieb:
Du hast in C# using() Blöcke. Die helfen oft. Python bietet das auch an (with). Ist ganz OK, halt eine light Variante von RAII.
using Blöcke zählen für mich zum Dispose Pattern. Und ja, ist in einigen Fällen ganz brauchbar, aber eben bei weitem nicht so mächtig wie RAII...
-
Shade Of Mine schrieb:
Kein Konzept dass ich kenne kommt an RAII ran. Welche Sprache bzw. welche Konzepte würdest du besser finden?
Leider ist das Problem in keiner mir bekannten Sprache richtig gut gelöst
Ich habe ja auch keine Sprache als Referenz bzw. Vergleich genannt, sondern mich auf die Problematik des Konzepts beschränkt (von der auch andere Sprachen betroffen sind).
Ich fand aber das Konzept der Conditions in Lisp sehr interessant, habe aber zu wenig Ahnung von Lisp im Detail, um hier die Nachteile im Gesamtzusammenhang der Sprachfeatures aufzudecken.dot schrieb:
Shade Of Mine schrieb:
Du hast in C# using() Blöcke. Die helfen oft. Python bietet das auch an (with). Ist ganz OK, halt eine light Variante von RAII.
using Blöcke zählen für mich zum Dispose Pattern. Und ja, ist in einigen Fällen ganz brauchbar, aber eben bei weitem nicht so mächtig wie RAII...
Das using-Statement ist RAII in .NET, da using genauso wie RAII auf dem Prinzip von "scoped usage" basiert. Der Unterschied ist, dass es sich auf unmanaged resources wie Datenbankhandles, Session IDs, Dongleverbindungen etc. beschränkt, denn managed resources verwaltet ja die CLR. Allerdings ist das Dispose-Pattern nicht besonders intuitiv. Der einzige Vorteil gegenüber RAII in C++ ist, dass man die Exceptions, die ein vom Finalizer aufgerufenes Dispose wirft, über den Finalizer der Klasse weiter nach oben geben kann, was ja in C++ nicht möglich ist. Ansonsten ist C++ RAII an der Stelle aber einfacher, weil man nicht extra an das using-Statement denken muss.
-
GPC schrieb:
Leider ist das Problem in keiner mir bekannten Sprache richtig gut gelöst
Ich habe ja auch keine Sprache als Referenz bzw. Vergleich genannt, sondern mich auf die Problematik des Konzepts beschränkt (von der auch andere Sprachen betroffen sind).Ich würde sogar soweit gehen zu sagen, dass es abgesehen von RAII keine aktzeptable Lösung gibt. Und ich habe schon sehr viele Sprachen durch. Alles ist schlechter als RAII.
Ich fand aber das Konzept der Conditions in Lisp sehr interessant, habe aber zu wenig Ahnung von Lisp im Detail, um hier die Nachteile im Gesamtzusammenhang der Sprachfeatures aufzudecken.
Ja aber ich habe keine praktische Erfahrung damit. Das ist aber das einzige Konzept dass uU an RAII ran kommt. uU ist es sogar besser.
-
Noch einmal im Thema nachgekakt: was wollt ihr denn?
Eine für alle Zeit perfekte Programmiersprache? Die hat es nie gegeben und wird es auch wohl nie geben! Oder wollt ihr einfach nur stabile lauffähige Programme schreiben, die ihr selbst odere andere morgen noch verstehen und bei Bedarf an geänderte Anforderungen anpassen könnt? Nichts ist schlimmer als ein Programm, das nach kurzem Einsatz auf den Müll geschmissen werden muss, weil niemand die neuen Wünschen realisiesen kann! 
-
berniebutt schrieb:
Noch einmal im Thema nachgekakt: was wollt ihr denn?
Eine für alle Zeit perfekte Programmiersprache?Es geht hier um Konzepte. Nicht um Sprachen.
Im idealfall will ich aber die perfekte Sprache. Klar. Wer nicht?
Wichtiger sind aber Konzepte. Die sind unabhängig von den jeweiligen Tools die man verwendet.
-
Kannst du nicht einmal irgendetwas schreiben, was zum Thema passt, anstatt immer mit Allgemeinplätzen wie "Es gibt keine perfekte Programmiersprache" um dich zu werfen?
-
Ne kanna nich, es gibt auch einen Begriff für solche Beantwortungsstategie der mir aber gerade nicht einfällt. Da aber solche Antworten die Diskussion keinen Deut voran bringen ignoriere ich sowas einfach und gut ist...
-
Shade Of Mine schrieb:
Es geht hier um Konzepte. Nicht um Sprachen.
Im idealfall will ich aber die perfekte Sprache. Klar. Wer nicht?
Wichtiger sind aber Konzepte. Die sind unabhängig von den jeweiligen Tools die man verwendet.Klar doch und genau oder nur da darum sollte es bei einem Thema wie diesem gehen!
Ich halte die gelegentlich an meinen Beiträgen geäusserte Kritik jederzeit aus, obwohl ich nicht von allem die volle Ahnung habe und auch nicht brauche. Ich selbst will nicht belehren, sondern mit guten Konzepten einfach selbst Programme schreiben. Meinetwegen mit veraltet geltenden Konzepten.Wer damit Geld verdienen will, muss ohnehin oft mit anderen Grundlagen denken!
-
Shade Of Mine schrieb:
Ich fand aber das Konzept der Conditions in Lisp sehr interessant, habe aber zu wenig Ahnung von Lisp im Detail, um hier die Nachteile im Gesamtzusammenhang der Sprachfeatures aufzudecken.
Ja aber ich habe keine praktische Erfahrung damit. Das ist aber das einzige Konzept dass uU an RAII ran kommt. uU ist es sogar besser.
Was ich lese, gefällt mir besser als RAII. Aber wie es sich in der Praxis dann tatsächlich bewährt, das weiß ich noch nicht. Ich habe mir aber für dieses Jahr fest vorgenommen, endlich mal Lisp zu lernen und auch was damit zu realisieren, vielleicht weiß ich dann mehr.
-
Als Verwender sowohl von C++ sowie C - APIs ist mir schon immer aufgefallen,
dass so eine C-Bibliothek viel unkomplizierter verwendet werden kann.
Oft sucht man ja nur die eine oder andere Funktion, die möglichst unabhängig
von irgend einem Kontext ein paar Parameter nehmen und irgend ein Resultat
zurückgeben soll. Sozusagen ein kontextunabhängiges Modul.
C-APIs bieten oft solche Funktionen an, aber bei C++ APIs
muss man meistens zuerst alle möglichen anderen Klassen und Kontexte
instanzieren oder gar selber ableiten, damit die Schnittstellen überhaupt
erst nutzbar sind, d.h. man bekommt irgendeine zusätzliche Logik aufgezwungen,
die den Entwicklern der C++ API vielleicht vorgeschwebt haben mag,
die man für's momentane Projekt aber eigentlich gar nicht benötigt.
Einzelne Funktionen oder Module aus einer Bibliothek 'ausschneiden' und
in einem neuen Programm wiederverwenden ist mit klassengebundenen, womöglich
auch noch virtuellen, C++ Funktionen halt leider nicht so ohne weiteres möglich
wie mit (global bekannten) C-Funktionen, wie sie von C-APIs gerne exportiert
werden. Könnte man auch so ausdrücken: C-APIs bieten öfter 'Magic Pushbuttons'
an, die man unkompliziert und sofort aufrufen kann, sofern man nur weiß, wie
man i.A. Funktionen aufruft. Bei C++ APIs muss man sich erst tage- und
wochenlang mit der Klassen-Design-Philosophie beschäftigen, die den API-
Entwicklern sinnvoll erschien (und dann kommt man erst dahinter, dass man
eigentlich etwas anderes gesucht hat bzw. dass man die geniale 'Freiheit'
und 'Flexibilität' ja hätte, in einer abgeleiteten Klasse die gesuchte
Wunsch-Funktion selber zu implementieren ...).
Also zur Entwicklung von anwenderfreundlichen APIs, Programmbibliotheken etc.,
die etwas mehr als nur ein paar abstrakte (gerne als 'flexibel' bezeichnet)
Schablonen anbieten sollen, sondern genau das, was so ein API-Verwender
erwartet: 'Self-containing Magic Pushbuttons', also einzelne Funktionen, die
auch unabhängig von irgend welchen größeren Kontexten funktionieren,
ist man mit C (mE) definitiv besser beraten als mit C++.
Wie es hier ja schon treffend formuliert wurde:
C ist konkreter (dafür u.U. auch unflexibler) als C++.
Das kann ich jedenfalls so (als API-Vergleicher) unterschreiben.
Hab ja alles mögliche versucht, OGRE, Irrlicht usw. und bin dann letzten
Endes bei der C-API SDL gelandet, die jetzt vielleicht nicht so viel auf einmal
kann, aber wenigstens braucht man zur Verwendung der Funktionen nicht erst
dutzende Tutorials durcharbeiten, sondern es genügt einfach nur C-Wissen
und die Funktionen tun auch genau das, was sie versprechen.
-
@MMOHansi:
Deine Beobachtungen sind richtig, deine Schlussfolgerungen allerdings totaler Unfug.
-
Hab ja alles mögliche versucht, OGRE, Irrlicht usw. und bin dann letzten
Endes bei der C-API SDL gelandetVersteh ich das richtig, dass du bei deinen Versuchen mit 3D-Engines schlussendlich auf eine 2D-Engine umgestiegenbist?
-
Willst du ein Framework schreiben welches sich gut in andere Sprachen integrieren lässt fällt C++ schon mal unterm Tisch, da ist C immer noch die beste Wahl weil C-Schnittstellen einfach viel mehr unterstützt werden.
OOP wird schon sehr stark überbewertet ist ähnlich wie die berühmte Cloud.
-
cinterface schrieb:
Willst du ein Framework schreiben welches sich gut in andere Sprachen integrieren lässt fällt C++ schon mal unterm Tisch, da ist C immer noch die beste Wahl weil C-Schnittstellen einfach viel mehr unterstützt werden.
Naja, die Schnittstelle ist das eine, die Implementierung das andere. Habe auch mal ein LADSPA-Plugin in C++ geschrieben, obwohl LADSPA eine C-Schnittstelle definiert. Das geht genauso wie man um C-Bibliotheken einen C++ Wrapper bauen kann, damit sie unter C++ noch leichter benutzbar wird (siehe gmpxx.h für GMP).
Aber ja, eine C-Schnittstelle ist -- zumindest, wenn es um vorkompilierte Bibliotheken geht -- um einiges stabiler und interoperabler; denn die C-ABI ist eher standardisiert als die C++-ABI auf einer Plattform. Die Standardbibliothek ist möglicherweise auch nicht binär-kompatible zwischen verschiedenen Compiler-Versionen.
