welche vorteile bietet c++ gegenüber c
-
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.
-
MMOHansi schrieb:
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.Habe ich anders beobachtet. Siehe zB. ffmpeg.
-
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.
Schon mal was von
extern "C"gehört?
Man kann ohne Probleme in C++ entwickeln und eine C Schnittstelle für andere Sprachen anbieten.@MMOHansi,
Kann ich so nicht bestätigen. Meistens hängt dies in erster Linie von der Dokumentation ab. Da können auch C Bibliotheken wahnsinnig kompliziert werden, wenn man nicht weiss, wie man die Funktion aufrufen soll, weil man nirgends Dokumentationen dazu findet (z.B. OpenCV, hässlich). Auf der anderen Seite gibt es C++ Bibliotheken, welche man sehr schnell versteht und anwenden kann, weil sie gut dokumentiert sind (z.B. SFML, simpel). Alles nur eine Frage der Dokumentation.
Und dann ist natürlich auch noch immer die Frage da, wie die Schnittstelle entworfen wurde: Mehr Richtung KISS oder nach Super-Power-Schnittstellen-Helden-Design?Grüssli
-
cinterface schrieb:
OOP wird schon sehr stark überbewertet ist ähnlich wie die berühmte Cloud.
welche OOP - a) namespace-OOP oder b) "echte" OOP in einer live-Objektwelt?
im Falle a) stimme ich zu.
-
!rr!rr_. schrieb:
cinterface schrieb:
OOP wird schon sehr stark überbewertet ist ähnlich wie die berühmte Cloud.
welche OOP - a) namespace-OOP oder b) "echte" OOP in einer live-Objektwelt?
im Falle a) stimme ich zu.Und ich dachte immer, Java hätte die "echte" OOP gepachtet. Wie man sich doch irren kann, wenn man mit C++-Bashern redet.
-
volkard schrieb:
!rr!rr_. schrieb:
cinterface schrieb:
OOP wird schon sehr stark überbewertet ist ähnlich wie die berühmte Cloud.
welche OOP - a) namespace-OOP oder b) "echte" OOP in einer live-Objektwelt?
im Falle a) stimme ich zu.Und ich dachte immer, Java hätte die "echte" OOP gepachtet. Wie man sich doch irren kann, wenn man mit C++-Bashern redet.
Naja, live realtime oop in der cloud as a service ist der aktuell beste Ansatz. Da kann C++ halt einpacken.
-
Shade Of Mine schrieb:
volkard schrieb:
!rr!rr_. schrieb:
cinterface schrieb:
OOP wird schon sehr stark überbewertet ist ähnlich wie die berühmte Cloud.
welche OOP - a) namespace-OOP oder b) "echte" OOP in einer live-Objektwelt?
im Falle a) stimme ich zu.Und ich dachte immer, Java hätte die "echte" OOP gepachtet. Wie man sich doch irren kann, wenn man mit C++-Bashern redet.
Naja, live realtime oop in der cloud as a service ist der aktuell beste Ansatz. Da kann C++ halt einpacken.
Willst du Buzzword-Bingo gewinnen? ... Jetzt man ehrlich gib mal ein Beispiel welche Technologie du meinst, damit ich es mir mal anschauen kann
-
Zeus schrieb:
Shade Of Mine schrieb:
Naja, live realtime oop in der cloud as a service ist der aktuell beste Ansatz. Da kann C++ halt einpacken.
Willst du Buzzword-Bingo gewinnen? ... Jetzt man ehrlich gib mal ein Beispiel welche Technologie du meinst, damit ich es mir mal anschauen kann
Er hat halt mal nicht technisch geantwortet, sondern über den Tellerand geschaut, und da schneidet C++ wirklich nicht so gut ab.
-
volkard schrieb:
....Er hat halt mal nicht technisch geantwortet, sondern über den Tellerand geschaut, und da schneidet C++ wirklich nicht so gut ab.
Das ist mir klar, mit soviel fantastische Attribute live und realtime - würde ich sorgar die mir bekannten Cloud-Techniken wie App Engine oder Azure ausschließen *gg* ... deswegen will ich wissen, welche Technologie er mit diesen Begriffen assoziiert.
