Lesbarer Quellcode ?

matimatiker schrieb:

Rückgabecodes statt Exceptions sind böse.
Rückgabecodes kann man ignorieren, tut man auch => unauffindbare Fehler entstehen.

Exceptions kann man in C++ aber auch ignorieren, was das ganze arbeiten damit komplizierter macht.

matimatiker

naja ist vorschrift für mich auf der arbeit. habe anfangs auch nicht den sinn davon verstanden. Diese Beispiele sind halt sinnvoller:

int* pInt;
SmartPtr<int> pInt;
int* bufInt;

und kommt mir nicht damit für bufInt std::vector vorzuschlagen. Um z.b. binary-dateien einzulesen ist es nutzlos.

matimatiker

naja schrieb:

matimatiker schrieb:

Rückgabecodes statt Exceptions sind böse.
Rückgabecodes kann man ignorieren, tut man auch => unauffindbare Fehler entstehen.

Exceptions kann man in C++ aber auch ignorieren, was das ganze arbeiten damit komplizierter macht.

Ja, aber um die zu ignorieren musst du aufwand betreiben. um rückgabekodes zu ignorien muss du keinen. im gegenteil um auf rückgabecodes zu testen musst du aufwand betreiben.

worauf ich hinaus will?
faulheit

Edit:
Nagut manchmal überwieder der aufwand eine fehler zu beseitigen den aufwand die entsprechende exception zu ignorieren...

vista

matimatiker schrieb:

Ja, aber um die zu ignorieren musst du aufwand betreiben. um rückgabekodes zu ignorien muss du keinen.

gute compiler geben ein warning aus, wenn man return values ignoriert...

matimatiker

vista schrieb:

matimatiker schrieb:

Ja, aber um die zu ignorieren musst du aufwand betreiben. um rückgabekodes zu ignorien muss du keinen.

gute compiler geben ein warning aus, wenn man return values ignoriert...

nicht alle compiler sind gut. es ist imho nicht sinnvol die warnung standardmäßig auszugeben. vielleicht ist es ja absicht dass ich einen rückgabewert ignoriere.
Anders gesagt der Aufwand ist immer noch da:
* guten compiler finden.
* entsprechende compiler-flag in der doku suchen
* compiler-flag anfügen

vista

matimatiker schrieb:

vielleicht ist es ja absicht dass ich einen rückgabewert ignoriere.

dann musst du die funktion so aufrufen

(void)funktion_die_was_zurueckgibt();

matimatiker

vista schrieb:

matimatiker schrieb:

vielleicht ist es ja absicht dass ich einen rückgabewert ignoriere.

dann musst du die funktion so aufrufen
(void)funktion_die_was_zurueckgibt();

hmm. wieder was gelernt.

SciFi

Ich wollte doch eigentlich nur wissen, ob mein Quellcode verständlich ist

In einem meiner Bücher stand in Vorwort geschrieben, dass jeder Programmierer den Stil des anderen repektieren möchte. Kein Witz. Stand wirklich da. Jeder hat so seine Eigenarten und persönliche Vorlieben. Wenn ich mir mein Programm nach ein paar Monaten wieder anschaue, dann finde ich es sehr hilfreich, wenn die Variablen einen entsprechenden präfix haben. Es liest sich einfach leichter und mann muss nicht immer nachsehen was es nun ist.

Vielleicht sieht einiges auf den ersten Blick komisch aus, aber das Programm besteht aus sehr sehr vielen Programmzeilen und die Logik kann man nicht in einer Funktion darstellen.

Mit Exepctions arbeite ich nicht so gerne. Dieses Try & Catch ist mir irgendwie suspekt. Ich will auch gar nicht, dass das Programm irgendwo rausspringt, sondern unter Berücksichtigung des Fehlers weitermacht. Ich habe vor ein paar Tagen mal einen Thread gelesen, dass viele die Exeption wirklich nur als Notbremse ansehen und nicht zur Standard Fehlerbehebung benutzen. Meine CMySQL kapselt nur die C API von MySQL auf eine bequeme Art und Weise (welche glaube ich gar keine Execption werfen kann) und das sich an den Standard SQL Befehlen etwas ändert glaube ich kaum.

Marc++us

SciFi schrieb:

Meine CMySQL kapselt nur die C API von MySQL auf eine bequeme Art und Weise (welche glaube ich gar keine Execption werfen kann)

Tut sie wohl nicht, denn Du schreibst ja immer noch "SELECT" im Klartext in den Quellcode.

rüdiger

SciFi schrieb:

Wenn ich mir mein Programm nach ein paar Monaten wieder anschaue, dann finde ich es sehr hilfreich, wenn die Variablen einen entsprechenden präfix haben. Es liest sich einfach leichter und mann muss nicht immer nachsehen was es nun ist.

Wozu musst du immer wissen "was es nun ist"? Es reicht doch wenn du weißt was es tun bzw. darstellen soll.

Mit Exepctions arbeite ich nicht so gerne. Dieses Try & Catch ist mir irgendwie suspekt. Ich will auch gar nicht, dass das Programm irgendwo rausspringt, sondern unter Berücksichtigung des Fehlers weitermacht. Ich habe vor ein paar Tagen mal einen Thread gelesen, dass viele die Exeption wirklich nur als Notbremse ansehen und nicht zur Standard Fehlerbehebung benutzen.

Viele Leute verstehen C++ falsch. C++ ist eben kein "verbessertes C", sondern eine eigene Programmiersprache... Aber das führt jetzt zu weit ab von der Diskussion.

Meine CMySQL kapselt nur die C API von MySQL auf eine bequeme Art und Weise (welche glaube ich gar keine Execption werfen kann) und das sich an den Standard SQL Befehlen etwas ändert glaube ich kaum.

Du hast aber im ganzen wenig Kontrolle darüber wann Exceptions geworfen werden oder nicht, wenn du nicht _alles_ selbst programmierst. Wie gesagt in deiner Funktion gibt es mindestens zwei Stellen an denen Exceptions geworfen werden können. Mindestens eine Stelle davon kann zu einem Ressource-Leak führen (sowohl in der Datenbank(!), als auch in deinem Programm).

Wilde Annahmen über Exception-Verhalten von fremden Funktionen zu treffen _ist_ gefährlich!

matimatiker schrieb:

naja schrieb:

matimatiker schrieb:

Rückgabecodes statt Exceptions sind böse.
Rückgabecodes kann man ignorieren, tut man auch => unauffindbare Fehler entstehen.

Exceptions kann man in C++ aber auch ignorieren, was das ganze arbeiten damit komplizierter macht.

Ja, aber um die zu ignorieren musst du aufwand betreiben.

Aufwand? Ich muss doch einfach garnichts machen. Wenn irgend ein netter Kollege auf die Idee kommt ein integer zu werfen, dann kracht es irgendwann mal. Wenn ich in Java eine Methode habe die eine normale Exception wirft, dann muss ich die mit throws angeben, und der Code compiliert nicht, wenn ich sie nicht abfange.

lolz

Die Diskussion macht so wenig Sinn, da scifi eine ganz andere Vorstellung vom Programmieren in C++ hat als ihr.

scifi du wirst erst einsehen, dass die anderen recht haben, wenn du dich mal auf diesen ganzen "c++-kram" einlässt. Als Einstieg wäre "Thinking in C++" geeignet, das gibts als open book

btw. Markus will darauf hinaus, dass du ORM benutzen solltest.