Unterschied c c++ c#

[wayynE]

Shade Of Mine schrieb:

wayynE schrieb:

Wie kommt man jetzt von Python auf soziale Komponente?

Man lernt Python idR nur wenn man sich wirklich dafuer interessiert.

Python wird in unserer Firma für alle möglichen Scriptingsachen eingesetzt und es gibt doch auch schon Vorlesungen usw. dafür.

[krümelkacker]

OOP Guy schrieb:

krümelkacker schrieb:

Aha. Sicher, dass Du da nicht etwas vergessen hast? Der Sinn von Exceptions ist doch, die "normale Ausführungslogik" nicht dadurch unleserlich zu machen, indem in jeder zweiten Zeile ein "if (hat_die_letzte_operation_nicht_geklappt)" steht.

Wenn Du auf den Fehler regieren willst, brauchst Du ein catch(),

Ja, und der Gag ist der, dass ich nicht jeden Funktionsaufruf separat in ein try{}catch(){} verpacken muss.

OOP Guy schrieb:

das lässt den Code sogar noch unschöner aussehen.

Ja, wenn Du sie falsch benutzt.

OOP Guy schrieb:

Wenn Du einen generellen Fehlerhandler brauchst, der z.B. das Programm beendet, wenn etwas schiefgeht, bekommst Du das in C mit atexit()/exit() hin. Für alles weitere reichen setjmp() und longjmp() völlig aus.

Ich hoffe, ich muss nie mit Dir zusammen arbeiten.

[OOP Guy]

krümelkacker schrieb:

OOP Guy schrieb:

krümelkacker schrieb:

Aha. Sicher, dass Du da nicht etwas vergessen hast? Der Sinn von Exceptions ist doch, die "normale Ausführungslogik" nicht dadurch unleserlich zu machen, indem in jeder zweiten Zeile ein "if (hat_die_letzte_operation_nicht_geklappt)" steht.

Wenn Du auf den Fehler regieren willst, brauchst Du ein catch(),

Ja, und der Gag ist der, dass ich nicht jeden Funktionsaufruf separat in ein try{}catch(){} verpacken muss.

Wie möchtest Du denn die Exception fangen, ohne try/catch?

krümelkacker schrieb:

OOP Guy schrieb:

Wenn Du einen generellen Fehlerhandler brauchst, der z.B. das Programm beendet, wenn etwas schiefgeht, bekommst Du das in C mit atexit()/exit() hin. Für alles weitere reichen setjmp() und longjmp() völlig aus.

Ich hoffe, ich muss nie mit Dir zusammen arbeiten.

Zu sehr C++ geschädigt? Keine Angst, das würde ich Dir schon abgewöhnen.

[QuoteBot]

Clown schrieb:

Exception Handling
Modernes Exception-Handling Teil 1
Modernes Exception-Handling Teil 2

[Search Engine Bot]

http://yosefk.com/c++fqa/exceptions.html

[volkard]

OOP Guy schrieb:

Clown schrieb:

Wie sehen deine Kenntnisse in C++ aus?

Mittelmäßig würde ich sagen. Kann man selber schlecht einschätzen.

(Tip: *Ein* Geisterfahrer?! Nein, das sind doch hunderte!)

OOP Guy schrieb:

Clown schrieb:

Wieviele Bücher zu C++ hast du schon gelesen?

Eins, den Stroustrup.

Das ist nicht viel.

OOP Guy schrieb:

Clown schrieb:

Seit wie langem programmierst du in C++?

Zuletzt bis vor zwei Jahren, etwa 4 Jahre lang. Seitdem programmierere ich nur noch in C# und C.

Du bist nicht der Erste, der vier Jahre lang C-Code in den C++-Compiler gehauen hat.
Aber VIER Jahre lang und das mit nur einem Buch?
Da muß ich ja jetzt denken, daß Du in der Zweiklassengesellschaft zur Oberschicht, den ausgelernt geborenen Embedded-Programmierern gehörst.

[krümelkacker]

OOP Guy schrieb:

krümelkacker schrieb:

Ja, und der Gag ist der, dass ich nicht jeden Funktionsaufruf separat in ein try{}catch(){} verpacken muss.

Wie möchtest Du denn die Exception fangen, ohne try/catch?

Oha! Damit hast Du Dich eigentlich schon disqualifiziert. Ausnahmen fängt man mit catch. Habe ich nie bestritten. Trotzdem gibt es hier keinen Widerspruch. Von jemandem, der die Ausnahmebehandlung von C++ versteht, würde man so eine Gegenfrage auch nicht erwarten. Die Frage deutet wirklich darauf hin, dass das Konzept noch nicht 100%ig verstanden worden ist. Das deutete sich auch schon in Deinem ersten Beitrag an, in dem Du behauptest, es gäbe keine signifikanten Unterschiede zwischen catch() und if().

Mehr kann man dazu nicht sagen. Du kannst jetzt auch nicht erwarten, dass Dir jemand das erklärt, was Du im Stroustrup zu dem Thema übersehen hast oder bei Dir in Vergessenheit geraten ist. Das ist Deine Aufgabe, das nachzuholen, wenn Du hier mitreden willst.

[OOP Guy]

volkard schrieb:

Aber VIER Jahre lang und das mit nur einem Buch?

Ja, für alles Weitere brauchte/brauche ich nur das MSDN.
Aber es ist IMHO kein Pluspunkt für C++, wenn Du unterstellst, dass 4 Jahre Beschäftigung damit nicht ausreichen, um es einigermassen zu beherrschen.

volkard schrieb:

Da muß ich ja jetzt denken, daß Du in der Zweiklassengesellschaft zur Oberschicht, den ausgelernt geborenen Embedded-Programmierern gehörst.

Niente, ich entwickle Windows-Anwendungen.

krümelkacker schrieb:

OOP Guy schrieb:

krümelkacker schrieb:

Ja, und der Gag ist der, dass ich nicht jeden Funktionsaufruf separat in ein try{}catch(){} verpacken muss.

Wie möchtest Du denn die Exception fangen, ohne try/catch?

Oha! Damit hast Du Dich eigentlich schon disqualifiziert. Ausnahmen fängt man mit catch. Habe ich nie bestritten. Trotzdem gibt es hier keinen Widerspruch. Von jemandem, der die Ausnahmebehandlung von C++ versteht, würde man so eine Gegenfrage auch nicht erwarten.

Ach ich bitte Dich! Dem Gesprächspartner Kompetenz abzusprechen ist ein ganz billiger rethorischer Trick, wenn man selbst keine Argumente hat.

[volkard]

OOP Guy schrieb:

volkard schrieb:

Aber VIER Jahre lang und das mit nur einem Buch?

Ja, für alles Weitere brauchte/brauche ich nur das MSDN.
Aber es ist IMHO kein Pluspunkt für C++, wenn Du unterstellst, dass 4 Jahre Beschäftigung damit nicht ausreichen, um es einigermassen zu beherrschen.

Weil C praktisch vollständig in C++ enthalten ist, braucht ein C-Programmierer jahrelang nichts dazuzulernen, wenn er einen C++-Compiler benuzt. Wenn Du es als Nachteil empfindest, nicht am Händchen genommen zu werden und zum Lernen gezwungen zu werden, dann ist C++ in dieser Hinsicht sehr schlecht.

[OOP Guy]

volkard schrieb:

OOP Guy schrieb:

volkard schrieb:

Aber VIER Jahre lang und das mit nur einem Buch?

Ja, für alles Weitere brauchte/brauche ich nur das MSDN.
Aber es ist IMHO kein Pluspunkt für C++, wenn Du unterstellst, dass 4 Jahre Beschäftigung damit nicht ausreichen, um es einigermassen zu beherrschen.

Weil C praktisch vollständig in C++ enthalten ist, braucht ein C-Programmierer jahrelang nichts dazuzulernen, wenn er einen C++-Compiler bentuzt. Meister bringen es auf Jahrzehnte. Wenn Du es als Nachteil empfindest, nicht am Händchen genommen zu werden und zum Lernen gezwungen zu werden, dann ist C++ in dieser Hinsicht sehr schlecht.

Ich will nicht sagen, dass ich der totale C++ Kenner bin, aber ich habe ausgiebig C++ Exceptions verwendet und weiss zumindest über diesen Teil von C++ bescheid. Zu was Anderem habe ich mich garnicht geäussert.

[*fricky]

Bashar schrieb:

fricky reloaded?

wie's scheint, bist du immer noch ziemlich traumatisiert. *fg*
@oop guy, Trolleyes
ich habe würdige nachfolger gefunden. *gg* sieht jedenfalls so aus. lasst euch von volkard nicht beeindrucken. er hat manchmal geistesblitze, aber c++ hat seinen geist über die jahre zusehends vernebelt.

[krümelkacker]

OOP Guy schrieb:

krümelkacker schrieb:

OOP Guy schrieb:

krümelkacker schrieb:

Ja, und der Gag ist der, dass ich nicht jeden Funktionsaufruf separat in ein try{}catch(){} verpacken muss.

Wie möchtest Du denn die Exception fangen, ohne try/catch?

Oha! Damit hast Du Dich eigentlich schon disqualifiziert. Ausnahmen fängt man mit catch. Habe ich nie bestritten. Trotzdem gibt es hier keinen Widerspruch. Von jemandem, der die Ausnahmebehandlung von C++ versteht, würde man so eine Gegenfrage auch nicht erwarten.

Ach ich bitte Dich! Dem Gesprächspartner Kompetenz abzusprechen ist ein ganz billiger rethorischer Trick, wenn man selbst keine Argumente hat.

Bleiben wir doch mal beim Thema. Welches Problem hast Du mit meiner "Der Gag ist..."-Aussage? Meine andere Erklärung dafür, warum Du diese Gegenfrage gebracht hast, ist die, dass Du ein wichtiges Wort übersehen haben könntest und wir somit aneinander vorbeigeredet hätten. Tipp: Das Wort könnte "separat" gewesen sein. Alternativ hätte man auch "einzeln" dafür einsetzen können.

Schönen Gruß,
kk

[Strukturierter Guy]

OOP Guy schrieb:

Shade Of Mine schrieb:

(und dabei mal den Schwachfug von OOP Guy aussen vor laesst, da dieser jeglicher grundlage entbehrt)

Ich habe mich hier nur über C++ Exceptions ausgelassen und dazu habe ich von Deiner Seite nichts gescheites gelesen.

Stimmt. Shade hat ja nur die zwei Artikel über modernes Exception-Handling geschrieben, er wird sicher keine Argumente für Exceptions haben. Wie könnte er auch.

[OOP Guy]

krümelkacker schrieb:

Bleiben wir doch mal beim Thema. Welches Problem hast Du mit meiner "Der Gag ist..."-Aussage? Meine andere Erklärung dafür, warum Du diese Gegenfrage gebracht hast, ist die, dass Du ein wichtiges Wort übersehen haben könntest und wir somit aneinander vorbeigeredet hätten. Tipp: Das Wort könnte "separat" gewesen sein. Alternativ hätte man auch "einzeln" dafür einsetzen können.

Du spielst darauf an, dass der erste Aufruf, der eine Exception auslöst andere überspringt? Und, was ist damit?

Strukturierter Guy schrieb:

Stimmt. Shade hat ja nur die zwei Artikel über modernes Exception-Handling geschrieben, er wird sicher keine Argumente für Exceptions haben. Wie könnte er auch.

Argumente eines Betriebsblinden wird er sicherlich hervorbringen können. Ich hoffe ja, es reicht für mehr. Aber das hat er noch nicht getan.
Das Wort "modern" in dem Zusammenhang finde ich auch irgendwie witzig.

[asc]

OOP Guy schrieb:

Du spielst darauf an, dass der erste Aufruf, der eine Exception auslöst andere überspringt? Und, was ist damit?

Du hast bislang gezeigt, das du recht wenig Kenntnisse in C++ hast, oder zumindest wie man Exceptions einsetzt (und auch das es keine 1:1 Entsprechung ist)

Beginnen wir also nochmal mit der Auflistung der Unterschiede von C++ Exceptions und dem typischen "C Fehlercode"-Behandlungen.

1. Exceptions fängt man genau da, wo man sie behandelt, dies kann einige Aufrufebenen von dem Fehler entfernt sein.
2. Mit Exceptions kann man längere if-Kaskaden umgeben, wenn es um die Allokierung und Freigabe von Ressourcen in Zusammenhang mit RAII-Techniken geht.
3. Ich habe schon etliche Programme gesehen wo man den Rückgabewert von Funktionen ignoriert hat (vergessen usw.), bei einer Exception FÄLLT dies auf.

Ungefragt: Man kann mit C++ kryptischen Code schreiben (wobei dies auch in jeder anderen Sprache geht, wenn auch die Templates hier besonders gerne dazu neigen - anderseits wird hier mit C++0x einiges entschärft). Aber ich behaupte auch das man in C++, wenn man es richtig macht, Code schreiben kann der besser verständlich ist als ein sauberer C-Code, da man mehr Strukturierungsmöglichkeiten hat.

[OOP Guy]

asc schrieb:

1. Exceptions fängt man genau da, wo man sie behandelt, dies kann einige Aufrufebenen von dem Fehler entfernt sein.

Ebenso kannst Du die Auswertung eines Fehlercodes verzögern.

asc schrieb:

2. Mit Exceptions kann man längere if-Kaskaden umgeben, wenn es um die Allokierung und Freigabe von Ressourcen in Zusammenhang mit RAII-Techniken geht.

Hast Du ein Beispiel dafür?

asc schrieb:

3. Ich habe schon etliche Programme gesehen wo man den Rückgabewert von Funktionen ignoriert hat (vergessen usw.), bei einer Exception FÄLLT dies auf.

Nein, C++ kennt keine checked Exceptions so wie Java. Du kannst in C++ Exceptions einfach ignorieren.

[Strukturierter Guy]

OOP Guy schrieb:

Argumente eines Betriebsblinden wird er sicherlich hervorbringen können. Ich hoffe ja, es reicht für mehr. Aber das hat er noch nicht getan.
Das Wort "modern" in dem Zusammenhang finde ich auch irgendwie witzig.

Was denkst du, wieso er "modern" schreibt? Weil try-catch jeder Java-Programmierer kann und das nichts besonderes ist. Shade Of Mine erklärt nicht die Grundlagen von Exceptions, dafür gibts einen separaten Artikel. Er zeigt moderne C++-Idiome wie RAII auf, die wunderbar mit Exceptions zusammenarbeiten und eben nicht selbstverständlich sind. Modern, weil diese Thematik vor allem in den letzten Jahren bekannt wurde (unter anderem durch Autoren wie Scott Meyers und Herb Sutter). Es gibt leider auch heute noch massig Programmierer, die C mit Klassen ausüben und keine Ahnung von solchen Techniken haben.

Ausserdem weist Shade ausdrücklich auf Vorteile gegenüber Fehlerbehandlung in C hin und sagt er einiges über exceptionsicheren Code. Lies den Artikel bitte, da steht wirklich sehr Wertvolles drin. Du musst ja nicht den ganzen lesen, aber zumindest den Vergleich mit herkömmlicher Fehlerbehandlung: http://www.c-plusplus.net/forum/viewtopic-var-t-is-219864.html

[krümelkacker]

OOP Guy schrieb:

krümelkacker schrieb:

Bleiben wir doch mal beim Thema. Welches Problem hast Du mit meiner "Der Gag ist..."-Aussage? Meine andere Erklärung dafür, warum Du diese Gegenfrage gebracht hast, ist die, dass Du ein wichtiges Wort übersehen haben könntest und wir somit aneinander vorbeigeredet hätten. Tipp: Das Wort könnte "separat" gewesen sein. Alternativ hätte man auch "einzeln" dafür einsetzen können.

Du spielst darauf an, dass der erste Aufruf, der eine Exception auslöst andere überspringt?

Genau, aber auch nicht nur das. Die Ausführung läuft in der "entsprechenden" catch-clause weiter, welche ganz wo anders stehen kann.

OOP Guy schrieb:

Und, was ist damit?

Damit wäre gezeigt, dass ich Recht hatte: Man muss nicht jeden Funktionsaufruf mit einem eigenen try/catch-Block umhüllen. Nochmal am Beispiel nur für Dich:

doof1 und doof2:

int foo(int a, int b, int&fehler) {          int foo(int a, int b, int&fehler) {
  int x,y,z;                                   int x = fun1(a,2*b,&fehler);
  try {                                        if (fehler) return 0;
    x = fun1(a,2*b);                           int y = fun2(2*b,a,&fehler);
  } catch (soundso&) {fehler=1; return 0;}     if (fehler) return 0;
  try {                                        int z = fun3(a-b,&fehler);
    y = fun2(2*b,a);                           if (fehler) return 0;
  } catch (soundso&) {fehler=2; return 0;}     return x+y+z;
  try {                                      }
    z = fun3(a-b);
  } catch (soundso&) {fehler=3; return 0;}
  fehler = 0;
  return x+y+z;
}

toll:

// Achtung, Funktion kann Ausnahme "soundso" werfen.
int foo(int a, int b) {
  x = fun1(a,2*b);
  y = fun2(2*b,a);
  z = fun3(a-b);
  return x+y+z;
}

Daraus folgt (indirekt): Um catch per if zu emulieren, würdest Du ggf sehr sehr viele if s benötigen, die die eigentliche Ausführungslogik nur unleserlicher machen würden, da schlechtere Trennung von Fehlererkennung und Fehlerbehandlung.

Daraus folgt: Fehlerbehandlung durch if s ist nicht annähernd das gleiche wie Fehlerbehandlung per catch (zB keine 1:1 Entsprechung).

Daraus folgt: Du hast Blödsinn erzählt.

War das so schwer?

Ich finde es sehr traurig, dass man das hier zu Fuß alles nochmal erklären musste -- und zwar jemandem, der sich an einer Diskussion mit dem Titel "C vs C++ vs C#" beteiligt und es besser hätte wissen müssen.

[DEvent]

volkard schrieb:

OOP Guy schrieb:

Clown schrieb:

Wie sehen deine Kenntnisse in C++ aus?

Mittelmäßig würde ich sagen. Kann man selber schlecht einschätzen.

(Tip: *Ein* Geisterfahrer?! Nein, das sind doch hunderte!)

OOP Guy schrieb:

Clown schrieb:

Wieviele Bücher zu C++ hast du schon gelesen?

Eins, den Stroustrup.

Das ist nicht viel.

OOP Guy schrieb:

Clown schrieb:

Seit wie langem programmierst du in C++?

Zuletzt bis vor zwei Jahren, etwa 4 Jahre lang. Seitdem programmierere ich nur noch in C# und C.

Du bist nicht der Erste, der vier Jahre lang C-Code in den C++-Compiler gehauen hat.
Aber VIER Jahre lang und das mit nur einem Buch?
Da muß ich ja jetzt denken, daß Du in der Zweiklassengesellschaft zur Oberschicht, den ausgelernt geborenen Embedded-Programmierern gehörst.

Das ist auch ein Problem mit C++. Man muss erst dicke Bücher von Stroustrup und andere Lesen, um überhaupt vernünftig mit C++ arbeiten zu können. Wenn man mal sagt, dass man X Jahre in C++ programmiert hat und das man an der Sprache A und B kritisiert wird man erstmal mit Büchern erschlagen.

Was ist denn an std::string "nicht Standard"?

Weil so gut wie jede Bibliothek mit ihrem String daherkommt und man am Ende doch einfach char* nimmt.

Nun, das ist eine komplett andere "Werkzeugkiste", die Du da aufmachst. Ich denke, C++ hat seine Existenzberechtigung. Es schafft low- und high-level Programmierung ohne Overhead ("zero overhead principle") zu kombinieren und ist damit auch bequem in "eingeschränkten Umgebungen" nutzbar.

Das ist auch so ein Mythos von C++ der gerne wiederholt wird.

Wenn sich da etwes an einer Schnittstelle ändert, müsste man dann nicht auch den Code anpassen, der diese Schnittstelle benutzt? Und warum sollte man anderen Code neu kompilieren, der überhaupt nichts von dieser Schnittstelle weiß?

Natürlich muss ich das. Aber in C++ muss ich trotzdem alles neu übersetzen. Auch muss ich das komplette Projekt neu übersetzen, wenn sich das private Interface ändert, weil auch das private Interface in den Header Dateien öffentlich ist. Was ich in C übrigens nicht habe. Das ganze wird durch die Pre-Compiled-Header etwas abgemildert, trotzdem ist es absurd das private Interface in den Header Dateien öffentlich machen zu müssen.

Kann das sein, dass Du nur Java und C kennst und glaubst, etwas über C++ zu wissen? Wie viele Erfahrungen hast Du mit C++ gemacht? Wie lange hast Du C++ programmiert? Welche Bücher hast Du zu C++ gelesen?

Ich habe C++ vielleicht an die 4 oder 6 Jahre programmiert. Danach bin ich zu Java gewechselt. C habe ich ebenso 4 oder 6 Jahre programmiert, verwende es aber immer mal wieder. Dann kenne ich noch Php, Ruby, Python, Groovy.

Aber nun werde ich wieder mit Büchern erschlagen. Eine Sprache wird nicht besser, wenn man darüber ganze Bibliotheken mit Büchern füllen kann. Im Gegenteil, eine Sprache ist sehr gut, wenn es darüber überhaupt keine Bücher gibt und man sie "einfach so" verstehen und effektiv benutzen kann. Eine Sprache ist ein Werkzeug um ein Problem zu lösen, dabei soll die Sprache so wenig Hürden wie möglich bieten. Wenn ich eine Sprache für ein Problem verwende und diese Sprache baut mir ganze Berge als Hindernisse auf, dann brauche ich keine Bücher zu lesen. Ich nehme eine andere Sprache und bin glücklich.

Das Argument mit den Büchern ist wie wenn ich ein Boot kaufe, es aber nur schwimmt wenn ich rückwärts fahre. Ich sage das Boot soll auch schwimmen wenn ich vorwärts fahre und du mich erstmal fragst wie viele Bücher ich über das Boot gelesen habe um überhaupt die Nachteile beurteilen zu können.

Jede andere Sprache steht dir nicht im Weg, du kannst dich nur auf das Problem konzentrieren. Außer eben C++.

Man eine Frage an die C++: Wie viele "smart pointer" gibt es inzwischen? Müsste bestimmt an die 50 sein, oder?

[irgendwer]

volkard schrieb:

Aber VIER Jahre lang und das mit nur einem Buch?

Ich hab noch kein einziges Buch zum Thema C++ gelesen und kann besser C++ als die meisten hier. Mir reicht es ein paar Forenbeiträge oder Internetartikel zu lesen. Gut, dass das aber sonst fast keiner kann, ist mir auch schon aufgefallen. Die meisten brauchen irendwie lauter Bücher um sich das Zeugs anzueignen. OOP Guy kann es anscheinend auch nicht.

asc schrieb:

Beginnen wir also nochmal mit der Auflistung der Unterschiede von C++ Exceptions und dem typischen "C Fehlercode"-Behandlungen.

1. Exceptions fängt man genau da, wo man sie behandelt, dies kann einige Aufrufebenen von dem Fehler entfernt sein.
2. Mit Exceptions kann man längere if-Kaskaden umgeben, wenn es um die Allokierung und Freigabe von Ressourcen in Zusammenhang mit RAII-Techniken geht.
3. Ich habe schon etliche Programme gesehen wo man den Rückgabewert von Funktionen ignoriert hat (vergessen usw.), bei einer Exception FÄLLT dies auf.

Interessanterweise werden in C++ auch fast keine Exceptions verwendet, man muss sich nur mal ifstream und Co anschauen. Wer verwendet die denn so, dass sie Exceptions werfen? Die meisten fragen failbits ab. In C++ bastelt man ne ganze Menge, wie z.B. save bool, rum, um Exceptions zu vermeiden. Exceptionssicheren Code in C++ zu schreiben ist auch relativ aufwendig.