Unterschied c c++ c#

[rüdiger]

Exceptionsicherheit ist in jeder Sprache mit Exceptions ein Problem. In Sprachen mit einem GC muss man sich nur um den Teil mit der Speicherfreigabe keine Sorgen machen. Aber das Datenstrukturen in einem ungültigen Zustand bleiben oder andere Ressourcen nicht richtig freigegeben werden.

[volkard]

OOP Guy schrieb:

volkard schrieb:

OOP Guy schrieb:

Er wollte ein C++ Beispiel, nicht Java.

In Java ist es üblich, die Reader so auf die Files zu setzen. Das darf man in C++ auch.

Gut, dann machen wir aus Deinem Code wieder C:

RssconlinuxPortdata *portdata = create_portdata("/dev/ttyUSB0\0");
NoiseData *noisedata = create_noisedata(portdata);
x = noisedata->read();

Und was haben wir jetzt bewiesen?

Daß Du in C keine Fehlerbehandlung hast und es doch so wirr wie oben machen mußt. In C++ werfen Konstruktoren oder read bei Fehlern einfach Exceptions und Destruktoren räumen auf. Damit muß ich mich dann nichtmehr belasten.

[OOP Guy]

rüdiger schrieb:

Exceptionsicherheit ist in jeder Sprache mit Exceptions ein Problem. In Sprachen mit einem GC muss man sich nur um den Teil mit der Speicherfreigabe keine Sorgen machen. Aber das Datenstrukturen in einem ungültigen Zustand bleiben oder andere Ressourcen nicht richtig freigegeben werden.

Sprachen mit Exceptions haben "finally" oder was vergleichbares. Ungültigen Zustand von Datenstrukturen hat man nur, wenn die Exception zu früh geworfen wird.

[OOP Guy]

volkard schrieb:

In C++ werfen Konstruktoren oder read bei Fehlern einfach Exceptions und Destruktoren räumen auf. Damit muß ich mich dann nichtmehr belasten.

Aber der Programmierer der Klassen muss die Fehlerbehandlung implementiert haben, gleiches könnte der Programmierer des C-codes tun.

RssconlinuxPortdata *portdata = create_portdata("/dev/ttyUSB0\0");  // Fehler: portdata ist null
NoiseData *noisedata = create_noisedata(portdata); // Fehler: Aufruf mit null erzeugt ungültiges NoiseData-Objekt
x = noisedata->read(); // Fehler: ungültiges Objekt gibt immer einen Fehlercode zurück

Und was haben wir jetzt damit bewiesen?

[volkard]

OOP Guy schrieb:

Und was haben wir jetzt damit bewiesen?

Daß man sich mit Unregistrierten besser auf keine Diskussion einläßt.

[otze]

OOP Guy schrieb:

RssconlinuxPortdata *portdata = create_portdata("/dev/ttyUSB0\0");  // Fehler: portdata ist null
NoiseData *noisedata = create_noisedata(portdata); // Fehler: Aufruf mit null erzeugt ungültiges NoiseData-Objekt
x = noisedata->read(); // Fehler: ungültiges Objekt gibt immer einen Fehlercode zurück

Und was haben wir jetzt damit bewiesen?

und was ist mit: gültiges portdata objekt wird übergeben, aber das Gerät kann nicht geöffnet werden? Und was ist mit: Gerät konnte korrekt geöffnet, aber nicht gestartet werden? So viele Fehlercodes kannste in nem Pointer auch nicht verstecken.

[OOP Guy]

otze schrieb:

So viele Fehlercodes kannste in nem Pointer auch nicht verstecken.

Stimmt, das habe ich vergessen, Pointer sind ja klitzeklein, haben bloss 3 oder 4 Bits.

volkard schrieb:

OOP Guy schrieb:

Und was haben wir jetzt damit bewiesen?

Daß man sich mit Unregistrierten besser auf keine Diskussion einläßt.

Es steht Dir frei, aus der Diskussion auszusteigen, wenn Du dich nicht wohl dabei fühlst.

[Clown]

OOP Guy schrieb:

otze schrieb:

So viele Fehlercodes kannste in nem Pointer auch nicht verstecken.

Stimmt, das habe ich vergessen, Pointer sind ja klitzeklein, haben bloss 3 oder 4 Bits.

Moment einmal, willst du gerade sagen, dass du die Fehlercodes in den Zeiger speichern willst. Dabei die Fehlercodes durchnummerieren willst über alle Funktionen und diese Durchnummerierung warten möchtest, so dass du am Ende vom Aufruf read auf alle Fehler überprüfen kannst? Und dazu halt noch das Risiko eingehst, dass einmal Speicher reserviert wird, dessen Zeigerwert mit einem Fehlerwert übereinstimmt?

Hier sind ja viel bessere Clowns als ich! Da muss ich meinen Beruf wechseln!

[OOP Guy]

Clown schrieb:

Moment einmal, willst du gerade sagen, dass du die Fehlercodes in den Zeiger speichern willst.

Nein, otze möchte das. Ich gebe einfach im vorliegenden Fall immer den Fehlercode INVALID_PORTDATA_OBJECT zurück.
[/quote]

[rüdiger]

OOP Guy schrieb:

rüdiger schrieb:

Exceptionsicherheit ist in jeder Sprache mit Exceptions ein Problem. In Sprachen mit einem GC muss man sich nur um den Teil mit der Speicherfreigabe keine Sorgen machen. Aber das Datenstrukturen in einem ungültigen Zustand bleiben oder andere Ressourcen nicht richtig freigegeben werden.

Sprachen mit Exceptions haben "finally" oder was vergleichbares. Ungültigen Zustand von Datenstrukturen hat man nur, wenn die Exception zu früh geworfen wird.

Und was willst du damit sagen?

[µngbd]

volkard schrieb:

Daß man sich mit Unregistrierten besser auf keine Diskussion einläßt.

Pauschalieren ist gar nicht unfair, oder?

[Shade Of Mine]

OOP Guy schrieb:

Nein, otze möchte das. Ich gebe einfach im vorliegenden Fall immer den Fehlercode INVALID_PORTDATA_OBJECT zurück.

Super Idee. Das ganze wird dann 2 Ebenen nach oben gereicht und ploetzlich hat sich errno geaendert, weil ja auch etwas anderes fehlschlaegt. Waehrend du einfach Exception Chaining machen kannst (OK, das ist in C++ nicht ganz ideal machbar) faellst du mit errno hier komplett auf die Nase.

Genial.

Koennen wir vielleicht versuchen auf einem ordentlichen Niveau zu reden? Was die Sprachfeatures betrifft ist C++ einfach besser geeignet als C. Denn egal was jetzt fuer Tricks kommen die man in C machen kann, die kann ich in C++ auch machen.

Die Frage also ist: was bietet C was C++ nicht bietet.

Das sind folgende Punkte:
leichter zu implentierende und verifizierbare Plattformen (Compiler+Library).

Und was Linus hauptpunkt ist: weniger Faulheit.

Desto abstrakter eine Sprache ist, desto fauler und laxer werden die Programmierer. zB nehmen C++ programmierer mittlerweile ja immer shared_ptr fuer alles und jeden. Im Prinzip gut, aber praktisch will ich das in einem Kernel nicht haben - da will ich scoped_ptr benutzen und shared_ptr nur dann wenn sie wirklich notwendig sind. Bestes Beispiel ist da wohl ein std::vector<shared_ptr<>> *brrr*. In 99% der Faelle will man einen ptr_vector<>.

Und das ist der Punkt: C zwingt einem mehr zum nachdenken. Das ist ein sozialer Vorteil, aber kein technischer.

Ich frage zB auch immer Leute ob sie Python koennen bevor ich ihnen ein Projekt gebe. Obwohl wir garnichts in Python machen. Weil die soziale Komponente wichtig ist. Aber man sollte nicht die soziale mit der technischen Verwechseln.

Denn die technische Seite sieht fuer C logischerweise nicht so toll aus (alle features von C habe ich in C++ ja auch) - also kann man maximal auf die Tools Ausweichen und auf Desktop Systemen sind die idR Gleichwertig.

[wayynE]

Shade Of Mine schrieb:

Ich frage zB auch immer Leute ob sie Python koennen bevor ich ihnen ein Projekt gebe. Obwohl wir garnichts in Python machen. Weil die soziale Komponente wichtig ist. Aber man sollte nicht die soziale mit der technischen Verwechseln.

Wie kommt man jetzt von Python auf soziale Komponente?

[OOP Guy]

Shade Of Mine schrieb:

OOP Guy schrieb:

Nein, otze möchte das. Ich gebe einfach im vorliegenden Fall immer den Fehlercode INVALID_PORTDATA_OBJECT zurück.

Super Idee. Das ganze wird dann 2 Ebenen nach oben gereicht und ploetzlich hat sich errno geaendert, weil ja auch etwas anderes fehlschlaegt. Waehrend du einfach Exception Chaining machen kannst (OK, das ist in C++ nicht ganz ideal machbar) faellst du mit errno hier komplett auf die Nase.
Genial.

Super Idee. Die Exception wird dann 2 Ebenen nach oben gereicht und ploetzlich wirft ein Destruktor eine weitere Exception, weil ja auch etwas anderes fehlschlaegt. Waehrend du einfach Fehlercodes verwenden kannst (OK, das ist in C manchmal etwas aufwändig) faellst du mit Exceptions hier komplett auf die Nase.
Genial.

[OOP Guy]

Und was haben wir jetzt damit bewiesen?

[Sinnl0s3]

OOP Guy schrieb:

Und was haben wir jetzt damit bewiesen?

nichts wie jedes mal...

[otze]

OOP Guy schrieb:

Und was haben wir jetzt damit bewiesen?

das mit unregs diskutieren Zeitverschwendung ist.

[OOP Guy]

Sinnl0s3 schrieb:

OOP Guy schrieb:

Und was haben wir jetzt damit bewiesen?

nichts wie jedes mal...

Nicht ganz. Wenn wir mal die beiden Codeschnipsel vergleichen (C und C++), dann sehen wir, dass sie sich sehr ähneln. Wo man in C++ mit Exceptionschmeisserei in einen alternativen Ausführungspfad verzweigt, tut man dies in C mit Rückgabewerten. Zum Abfangen von Fehlern nimmt man in C if() während in C++ catch()-Anweisungen stehen. Offensichtlich gibt es ausser diesen technischen Feinheiten keinen nennenswerten Unterschied. Ein catch(...) (alle Fehler) in C++ ist leicht ersetzt durch ein if (errorcode < 0). So wie es aussieht, sind Exceptions nicht unbedingt die grosse Bereicherung, die C++ von C abhebt. Es muss also noch was anderes sein. Klassen? Templates vielleicht?

BTW: OK, die Sache mit den C-Fehlercodes ist flexibler, denn sie macht es uns einfacher Aktionen zu wiederholen und eine feinkörnigere Fehlerbehandlung ist auch möglich. Aber lassen wir diese Haarspalterei.

[OOP Guy]

otze schrieb:

OOP Guy schrieb:

Und was haben wir jetzt damit bewiesen?

das mit unregs diskutieren Zeitverschwendung ist.

Entschuldige bitte, dass ich Dir widersprochen habe, O du großer C++ Meister.

[Clown]

@OOP Guy,
Und nun der Witz des Tages:
Wie sehen deine Kenntnisse in C++ aus? Wieviele Bücher zu C++ hast du schon gelesen? Seit wie langem programmierst du in C++? Wieviele Programme hast du schon in C++ geschrieben? Wie stark hast du dich mit C++ auseinander gesetzt?