Warum programmiert ihr in C?

Nun komm mal runter Volkard, du willst doch hier nicht ernsthaft behaupten man brauche immer OOP um mittlere bis größere Programme zu entwickeln. Das ist absoluter Unsinn, sorry. OOP kann helfen kann aber auch genauso sehr hinderlich sein. Auf keine Fall ist OOP ein muss für gute und auch große Software. Leg dich mal wieder hin und schlaf dich aus vielleicht klappt es dann mit dem Nachdenken etwas besser.

mgaeckler

Meinung001 schrieb:

Ob ich C++ richtig kann? Wohl eher nicht, aber ich habe es wahrlich versucht zu lernen. Nach ein paar Monaten, in der ich mal mehr mal weniger gelernt hatte, war dann irgendwann die Motivation dahin.

Hallo,

jetzt würde mich mal interessieren, was denn die Probleme beim Erlernen von C++ war.

C++ ist doch nur eine sinnvolle Erweiterung der Sprache C um OOP-Konzepte. Diese sind meiner Meinung nach nicht sehr schwer zu verstehen. Und wenn Du Java einigermassen kannst, sollte es doch auch mit C++ nicht so schwer fallen.

Betrachten wir doch einfach mal die wichtigsten Änderungen:

1. Was heißt eigentlich OOP?
Bei der objektorientierten Programmierung werden Datenstrukturen und Methoden enger verzahnt. In C habe ich auf der einen Seite Strukturen und auf der anderen Seite Methoden. Methoden können als Parameter ein oder mehrere Strukturen bekommen oder auch nicht. Wie das verknüpft wird, bleibt den Programmierer überlassen. Es ist aber auch in C möglich, objektorientiert zu programmieren. Man/frau muß halt das, was der Compiler implizit bei C++ macht, die in C explizit ausformulieren. Beispiel stdio:

Statt

fprintf( file, "xxx" );

würde man dann das, in C++ schreiben

file->fprintf( "xxx" );  // wenn es denn sowas gäbe

2. Kapselung
In C++ kann der Zugriff auf Elemente einer Struktur gesteuert werden. So etwas gibt es in C direkt nicht, ich kann aber damit erreichen, daß nicht wild in den Strukturen herumgepfuscht wird. Wenn man die entsprechenden Getter und Setter Methoden implementiert, hat man trotzdem die Möglichkeit von überall aus, die Elemente zu ändern ist also genauso flexibel wie in C. Wenn diese Getter und Setter Methoden auch noch inline sind, kosten sie auch keine Performance.

Nun werden Cler sagen, was habe ich davon? Ganz einfach, wenn ein Element geändert wird und ich möchte beim Debuggen herausfinden wo das passiert, brauch ich nur einen Breakpoint auf die Setterfunktion setzen und warten, bis der Debugger das Programm unterbricht.

Nun werden die Cler sagen, das geht auch mit Watchpoints. Dann sage ich, daß dieses beim Debuggen das Programm ziemlich verlangsamen kann und dieses dadurch nur mühsamer wird.

Ein weiterer Vorteil der Kapselung ist, daß es leichter ist, das Programm zu ändern, wenn sich im Laufe der Zeit die Logik des Programmes so ändert, daß beim Verändern eines Elements auch noch ein anderes Element angepasst werden muß oder irgendwelche Plausibilitäten eingebaut werden müssen.

In C müsste ich alle Stellen heraussuchen, in denen das passiert und entsprechend anpassen, wer sauber in C++ realisiert hat, braucht nur genau diese eine Stelle suchen und korrigieren.

Praktisch ist auch, daß ich die Kapselung nicht immer nutzen muß. Ich benutze auch in meinen C++ Klassen nach wie vor normale Strukturen, wenn mir der Extraaufwand mit Getter und Setter nicht sinnvoll erscheint. Und wenn es dann irgendwanneinmal doch geändert werden muß, zeigt mir schon der Compiler, wo Nacharbeiten erforderlich sind.

3. Vererbung
Das A&O eines komplexen Programmes sind die Datenstrukturen. Wenn die Datenstrukturen sauber formuliert sind, hat man schon die halbe Miete bei der Erstellung des Programmes. Dies gilt für jede Programmiersprache und auch beim Design eines Datenbankschemas.

Hier bietet ein C++ eine ganze Reihe von Werkzeugen, die dem C-Programmieren fehlen. Ich kann beispielsweise einen Container schreiben, der eine abstrakte Datenstruktur speichern kann und jemand anderes erweitert diese abstrakte Struktur und kann trotzdem den Container benutzen. Wer schon einmal sich mit der OLE2 Api von Windoof beschäftigt hat, weiß was für einen Vorteil das bieten kann.

4. Exceptions
Man stelle sich mal ein Programm vor, das eine sehr tiefe Aufrufhierarchie. Ganz weit unten passiert ein Fehler und es heißt Kommando zurück. In C ist es einfach Routine, die Rückgabewerte aller Funktionen zu überprüfen und gegebenenfalls zu reagieren. Solche Routineaufgaben können aber problemlos vom Compiler erledigt werden und wenn dann doch mal eine besondere Fehlerbehandlung erforderlich sein sollte, die der Compiler nicht automatisch erledigen kann, macht man halt eine try..excpetion block.

usw usf.

Das besonders tolle an C++ ist, ich muß das Zeug nicht benutzen, ich kann wo immer es adäquat ist, auch meine normalen C-Funktionen benutzen. Beispiel:

Niemand zwingt mich std::vector zu benutzen, wenn ich ein array brauche, dessen Größe schon vor der Speicheranforderung bekannt ist und das ich nur für einen Überschaubaren bereich brauche. malloc und free dürfen auch in C++ benutzt werden. Wer Klassen mit Konstruktoren benutzt, verwendet halt new[] und delete[].

Grundätzlich gilt:
C++ Programme sind nicht automatisch langsamer als C-Programme. Wer die Vorteile der STL nicht braucht, muß sie nicht nutzen. Wer sie braucht, wird auch in C keine großartigen besseren Ergebnisse abliefern. Und wenn doch, baut man sich halt seine eigenen Klassen.

C Programme sind aber auch nicht automatisch absturzgefährdeter. Man kann auch in C sauber programmieren und auch mit C-Methoden kann man sehr große Projekte realisieren. Ich habe beispielsweise vor Jahren mal ein DTP-System für Unixkisten gemacht. Das war reines C, sogar nicht einmal Ansi C, Es war K&R C. (Da merke ich mal wieder wie alt ich eigentlich schon bin)

Nochj ein Satz: OOP ist nicht erforderlich, es erleichtert aber manche Aufgaben ungemein.

mfg Martin
P.S.: Ich würde mir hier wünschen, daß diese Diskusion wieder in sachlichere Bahnen gelenkt wird. Es ist nicht zielführend sich gegenseitig zu beschimpfen und es bringt erst recht nichts, über die Deutschkentnisse mancher Forenteilnehmer herzufallen, wenn einem die Argumente ausgehen.

Bei OOP kann man sehr schnell viel falsch machen. Es ist sehr schwierig gute OO-Programmierer zu finden, da OOP wirklich nichts für Anfänger ist. Zumal ist C++ nicht wirklich eine Objektorientierte Programmiersprache jeder der OOP ernsthaft betreibt wird einen weiten Bogen um C++ machen, wenn er denn das kann. Ich schätze mal man braucht gute 2 Jahre um C++ und OOP einigermaßen zu erlernen, das ist vielen einfach zu aufwändig da es noch weit mehr zu lernen gibt als ein Paradigma und eine Programmiersprache.

volkard

nichtdeinErnstoder schrieb:

Nun komm mal runter Volkard, du willst doch hier nicht ernsthaft behaupten man brauche immer OOP um mittlere bis größere Programme zu entwickeln.

Nicht notwendig. Nur ungemein praktisch. Für mich sogar weniger wegen der Übersicht, als für die geordnete Ressourcenverwaltung. Deswegen komme ich mit der OO von Perl supi zurecht, während die von C# mir fast nichts gibt.

nichtdeinErnstoder schrieb:

Das ist absoluter Unsinn, sorry. OOP kann helfen kann aber auch genauso sehr hinderlich sein.

Da muß man einfach schlau sein, und die OOP nicht dort einsetzen, wo sie stört. Wir müssen ja nicht OO-pseudoverpflichtende Sprachen wie Java nehmen.

Scheppertreiber

P.S.: Ich würde mir hier wünschen, daß diese Diskusion wieder in sachlichere Bahnen gelenkt wird. Es ist nicht zielführend sich gegenseitig zu beschimpfen und es bringt erst recht nichts, über die Deutschkentnisse mancher Forenteilnehmer herzufallen, wenn einem die Argumente ausgehen.

Danke Martin - das war der erste sachliche Beitrag in diesen Thread.

Ich denke diese Antwort fasst es auch ganz gut zusammen:

:Why not using C++ for GTK-G ?

Why using it?

:I saw you were using such notation '[object]_[method]'. You widly used
:'[object]_init' or '[object]_close' or '[object]_shutdown' and this
:looks like objects initialisations and destruction. So why ?

Yes, this is modularity.

Actually, the C code of GTKG is a mix of procedural style and OO style.

I don't like C++. It's not really an OO language. At first sight it
might appear to be one, but it is not. And it's so easy to write a mess
in C++ that, brrr... it's not very encouraging.

(I can develop why I think C++ is not an OO language if you want.)

Furthermore, it takes better engineers to do OO design properly.
Trivial OO design is easy, good OO design is hard. It would be harder
to find good OO programmers than it is to find good C programmers.

Finally, I don't know how good gcc is as a C++ compiler.

But yes, I confess re-writing in an OO language would be nice.
Unfortunately, the only OO language I know of is Eiffel.

Raphael

C++ 30mal langsamer als C bekommt jeder hin der sich nicht sehr gut mit C++ und OOP auskennt. Da kann man in C++ so viel falsch machen und hat schnell ein Programm welches von der Performance an eine Scriptsprache erinnert. Viele Anfänger denken nur weil sie in C++ programmieren ist ihr Programm automatisch schneller als Beispielsweise ein Java-Programm. Es wird aber nur wirklich schneller sein wenn man sich extrem gut in C++ und OOP auskennt und das tuhen die wenigsten.

dot

Du sagst also C++ ist eine schlechte Sprache weil so viele Leute nicht damit umgehen können!?

Cppungleichimmerschnell schrieb:

C++ 30mal langsamer als C bekommt jeder hin der sich nicht sehr gut mit C++ und OOP auskennt. Da kann man in C++ so viel falsch machen und hat schnell ein Programm welches von der Performance an eine Scriptsprache erinnert. Viele Anfänger denken nur weil sie in C++ programmieren ist ihr Programm automatisch schneller als Beispielsweise ein Java-Programm. Es wird aber nur wirklich schneller sein wenn man sich extrem gut in C++ und OOP auskennt und das tuhen die wenigsten.

Falsch. Es ist genau anders herum. In C++ musst du VERDAMMT viel falsch machen, damit das Programm mal langsam wird. Ganz anders als in Java.
Da soll mir mal einer der C "Experten" ein Beispiel zeigen, in dem C++ Code 30mal langsamer ist als vergleichbarer C Code. Wir wissen alle, dass wir so ein Beispiel nie sehen werden.

mgaeckler

OOPnotfornoobs schrieb:

Bei OOP kann man sehr schnell viel falsch machen. Es ist sehr schwierig gute OO-Programmierer zu finden, da OOP wirklich nichts für Anfänger ist.

Das ist keine Eigenschaft von OOP. Jeder, der nicht in der Lage ist, seine Datenstrukturen vernünftig zu modelieren, wird mit jeder Sprache scheitern. Andersrum gilt, jeder, der seine Daten vernünftig modelieren kann, wird mit praktisch jeder Sprache erfolgreich sein.

OOPnotfornoobs schrieb:

Zumal ist C++ nicht wirklich eine Objektorientierte Programmiersprache jeder der OOP ernsthaft betreibt wird einen weiten Bogen um C++ machen, wenn er denn das kann. Ich schätze mal man braucht gute 2 Jahre um C++ und OOP einigermaßen zu erlernen, das ist vielen einfach zu aufwändig da es noch weit mehr zu lernen gibt als ein Paradigma und eine Programmiersprache.

Das ist aber meiner Meinung nach der große Vorteil von C++ im Gegensatz zu anderen reinen OOP-Sprachen. Ich kann die Vorteile nutzen, muß aber nicht.

mfg Martin

volkard

KennerDerUnfähigen schrieb:

Da soll mir mal einer der C "Experten" ein Beispiel zeigen, in dem C++ Code 30mal langsamer ist als vergleichbarer C Code. Wir wissen alle, dass wir so ein Beispiel nie sehen werden.

Naja, wenn man *kein* C++-Buch oder Tutorial gelesen hat, sondern sich den Code aus Beispielen zusammenschustert, dann könnte man auf die Idee verfallen, Einzelbuchstaben statt un char in std::string zu speichern. Zusammen mit einer netten Schleife, die was triviales macht, zum Beispiel eine ASCII-Tabelle in eine Datei schreibt... Nee, nicht trivial genug. Ausgabe dauert viel zu lange.
Zum Beispiel zählt, wie oft ein bestimmter Buchstabe vorkommt, nee, wozu da die Zwischenvariable.
Aber wenn ich mir einen ganzen Tag Zeit nehme, kann ich wohl ein hübsches Beispiel konstruieren, das auf den ersten Blick glaubwürdig aussieht, als würde ein Nube sowas schreiben, und zugleich Faktor 30 packt.
Vielleicht was mit std::vector als By-Value-Übergabe in rekursiver Permutationen-Funktion? Zu un-noobig. Wer sowas bauen kann, macht den Fehler sicher nicht.
Das Problem ist faszinierend.

Scheppertreiber

Selbst Faktor 2 kann in der Praxis viel ausmachen, bei längeren
Programmlaufzeiten bzw größeren Datenmengen zB den Unterschied
zwischen 1 und 2 h "System nicht verfügbar".

30 halte ich auch für übertrieben ...

wenn man in c++ c programmiert sollte es auch gleich schnell/langsam sein, oder?

volkard

__-- schrieb:

wenn man in c++ c programmiert sollte es auch gleich schnell/langsam sein, oder?

Ja, man kann in C++ stets nach C runter und sicher null Mehrkosten haben.
Vorausgesetzt man hat einen Compiler mit einem vernünftigen Exception-Modell, das einem keine Mehrkosten auferlegt für Code, der mit Exceptions gar nichts zu tun hat. Was ich zum Beispiel (noch?) nicht vestehen kann, ist, daß jemand als erste Zeilen in der main das argv[] erstmal in einen vector<string> kopiert.

Außerdem hat C++ "zero abstraction overhead". Nur, weil man aus zusammengehörenden Funktionen um eine Struktur eine Klasse bastelt, muß man noch keinen Takt mehr bezahlen.

Man kann darüberhinaus in Teilen Geschwindigkeiten erreichen, die mit C nur sehr umständlich zu erreichen wären, sort, unordered_map, blitz++. Dadurch basteln Anfänger in C++ natürlich schnelleren Code als vergleichbare Anfänger in C. sort (z.B. Intro-Sort) und map(z.B. AVL-Baum) sind ja so nah!

Und Compilerbauer können Exceptions so schlau implemetieren, daß sie keine Laufzeitkosten verursachen, solange sie nicht fliegen. Für Exceptions, die sehr selten fliegen (wie es sein soll), oder wo es wegen Programmabbruch oder Benutzerinterkation völlig irrelecant ist, wie lange es im Falle einer Esxception dauert, ist man also schneller als in gleich fehlerrobustem C-Code.
Das ist ein knallharter Geschwindigkeitsvorteil für C++.

Nee, das kann nicht sein. Dann wäre ja das Fazit, daß sowohl Anfänger als auch Profis in C++ schnelleren Code basteln. Und daß nur, wer nicht bereit ist, C++ zu lernen, in C schnelleren Code bastelt. Gell, das kann nicht wahr sein, weil es nicht wahr sein darf.

Och C++ bekommste als Anfänger ganz schnell langsam. Mit OOP etwas unglücklich designt dann noch Kopiekonstruktoren schlecht implementiert und schon haste einen Overhead vom feinsten. Das ganze dann noch unter Linux wo die C++ Runtime eh schon um einiges langsamer sind als jene von C und evola haste Schneckencode.

Wir sind zwar hier in einem C++ Forum und man sollte die letzten C++ler die es noch gibt auch nicht verachten aber ein OOP-Fan sein und C++ nutzen ist schon ein wenig pervers. Noch eine allgemeine Kritik hätte ich. Mit eurem Webzeugs wird heute sicherlich viel mehr gemacht als mit dem komischen C++ also benennt das um oder ihr gebt damit zu noch in den 90igern geblieben zu sein.

Hugo8723 schrieb:

Och C++ bekommste als Anfänger ganz schnell langsam. Mit OOP etwas unglücklich designt dann noch Kopiekonstruktoren schlecht implementiert und schon haste einen Overhead vom feinsten. Das ganze dann noch unter Linux wo die C++ Runtime eh schon um einiges langsamer sind als jene von C und evola haste Schneckencode.

Wir sind zwar hier in einem C++ Forum und man sollte die letzten C++ler die es noch gibt auch nicht verachten aber ein OOP-Fan sein und C++ nutzen ist schon ein wenig pervers. Noch eine allgemeine Kritik hätte ich. Mit eurem Webzeugs wird heute sicherlich viel mehr gemacht als mit dem komischen C++ also benennt das um oder ihr gebt damit zu noch in den 90igern geblieben zu sein.

Du hast Ahnung von der realen Welt.

volkard

Hugo8723 schrieb:

Och C++ bekommste als Anfänger ganz schnell langsam. Mit OOP etwas unglücklich designt dann noch Kopiekonstruktoren schlecht implementiert und schon haste einen Overhead vom feinsten.

Kopierkonstruktoren KANN man nur implementieren, wenn man Referenzen benutzt. Anderenfalls kommt ein Compilerfehler. Folglich kennt man Referenzen. Folglich ruft man diese Kopierkonstruktoren nicht unnötig auf. Folglich ist das von Dir geschilderte Problem inexistent. Oder?
Bastle doch mal Argumente, die man nachvollziehen kann.

volkard schrieb:

Hugo8723 schrieb:

Och C++ bekommste als Anfänger ganz schnell langsam. Mit OOP etwas unglücklich designt dann noch Kopiekonstruktoren schlecht implementiert und schon haste einen Overhead vom feinsten.

Kopierkonstruktoren KANN man nur implementieren, wenn man Referenzen benutzt. Anderenfalls kommt ein Compilerfehler. Folglich kennt man Referenzen. Folglich ruft man diese Kopierkonstruktoren nicht unnötig auf. Folglich ist das von Dir geschilderte Problem inexistent. Oder?
Bastle doch mal Argumente, die man nachvollziehen kann.

Wieso fragst du extra nach? Du siehst doch, dass er offenbar ein weiteres C Kind ohne Ahnung von C++ ist (zeigt ja sein nicht mögliches CCtor Beispiel).

Auffällig: C ler = Unregs, Trolle, Unstudierte
C++er: Registriert, Sachkenntnis, fast alle studiert

Mein Bild von C-Fricklern bestätigt sich. Sind halt doch eher ungelernte Typen/Fachinformatiker, die so vor sich hin wursteln in kleinen Betrieben und sich am Ende auch noch haxx0r vorkommen.

hehehehe schrieb:

Auffällig: C ler = Unregs, Trolle, Unstudierte
C++er: Registriert, Sachkenntnis, fast alle studiert

zum glück kenn ich ja nichts anderes als c... und muß mich hier von dir blöd anmachen lassen

ums nochmal kurz und knapp auf den punkt zu bringen, mir gefällt die syntax nicht. das ganze referenzen geschubse mag ich auch nicht. operator überladung von shift für strings ist eine krankheit. wenn ichs schnell hinschmieren will, nehm ich was anderes. auch wenn c++ 10mal so schnell wär würds mir immer noch nicht gefallen. und selbst wenn ich studieren würde hätt ich trotzdem keinen bedarf in meiner freizeit etwas zu verwenden was mir einfach nicht gefällt. dafür muß es auch gar keine plausiblen gründe geben.