Destructor-Handling bei Exception aus einem Constructor

Finnegan

Nathan schrieb:

Letzteres ist aber ein deutlich wichtigeres Prinzip. Programming in the future sense. Du weißt nie, wie lange dein Code noch lebt. Irgendwann könnte ein anderer Programmierer da Code einfügen, der wirft, weil er schnell etwas fixen muss und/oder nicht auf Exceptionsafety achtet. Man muss so programmierern, das solche Fehler vermieden werden.

Ja, das stimmt auch. Dieser kurze Code ist auch eigentlich ein schlechtes Beispiel dafür, was ich hier eigentlich vermeiden möchte: Dass Code Stück für Stück komplizierter wird und damit schwerer zu lesen und zu warten wird. Wenn man alle zukünftigen Eventualitäten berücksichtigt, kann sowas durchaus auch passieren. Schwer zu beurteilen, wo man da die Grenze zieht, und darüber kann man sicher lange diskutieren. Einen unique_ptr zu erstellen, der direkt in der nächsten Zeile seine Besitzansprüche aufgibt kommt mir etwas übertrieben vor - ich bevorzuge da etwas weniger Rauschen im Code, auch wenn ich ebenfalls Verfechter von Code bin, der hilft, zukünftige Fehler zu vermeiden (wie gesagt, ist alles etwas zweischneidig).

Nathan schrieb:

Darüber hinaus verletzt gezeigter Code jetzt auch nicht gerade KISS.

Wie gesagt, nach meinem Bauchgefühl schon, weil es ein kleines bisschen unnötige Komplexität reinbringt durch den zusätzlichen unique_ptr . Vielleicht wäre es besser das new in den Funktionsaufruf zu packen:

c_api_with_callback(new std::shared_ptr<Type>(other));

... und so deutlich zu machen "es ist nicht geplant, das hier etwas dazwischen steht", und " c_api_with_callback trägt jetzt die Verantwortung für den Speicher".

Finnegan

Finnegan

hustbaer schrieb:

Und wenn man sich diese Dinge mal überlegt hat, dann sollte man mMn. solchen Code auch nicht mehr schreiben. Weil man schliesslich bereits weiss dass es problematisch ist, und wie man es besser macht.

Wie bereits gesagt, da stimme ich generell zu! Ich habe lediglich ein Problem mit "immer" und "nie" - lieber "fast immer" und "fast nie", da es fast immer Ausnahmefälle gibt, und sei es nur für die handvoll Leute, welche die C++-Standardbibliothek programmieren, damit man überhaupt erstmal das Handwerkszeug hat, um auf solche Konstrukte verzichten zu können

Finnegan

hustbaer schrieb:

Ja, und deine Antwort ist immer noch falsch.
Weil "erst aufräumen, dann werfen" in einem Programm mit Exceptions nix verloren hat. Weil es zu Problemen (=Bugs) führt. Weil es falsch ist.

es ist also falsch, weil es falsch ist. Ja, das klingt überzeugend

hustbaer

@Finnegan
Da hast du schon recht.
Blöd ist bei "fast immer" bzw. "fast nie" nur, dass es viele Idioten gibt die es einfach überlesen, weil sie meinen eh alles besser zu wissen.

@großbuchstaben
Du musst den Rest meiner Beiträge lesen, da stehen genug Begründungen.

ich muß gar nichts

hustbaer

Natürlich nicht.
Ich muss aber auch nix, also z.B. dich nicht ernst nehmen.

Columbo

@hustbaer: Können wir uns darauf einigen dass man auf Menschen, die man nicht ernst nehmen möchte, nicht antworten muss?

hustbaer

@Arcoth
Grundsätzlich ja.
In diesem speziellen Fall ... nein.

Ich hoffe du kannst das nachvollziehen. Wäre etwas mühsam das erklären zu müssen.

doch, erklär mal genau - heiter' mich auf, nach diesem arbeitsreichen Tag

hustbaer

Achje...
Wenn du es nicht für nötig befindest meine Beiträge vollständig zu lesen, wieso sollte ich deine Einwände auf diese Beiträge dann ernst nehmen?

Klar musst du nicht lesen was ich schreibe. Nur wenn du es nicht tust, dann sehe ich auch keinen grossen Sinn darin deine an mich gerichteten Beiträge ernst zu nehmen.

Sollte doch irgendwie nachvollziehbar sein, oder?

hustbaer schrieb:

Du musst den Rest meiner Beiträge lesen, da stehen genug Begründungen.

hustbaer schrieb:

Klar musst du nicht lesen was ich schreibe.

hustbaer

Dir das implizierte "wenn du mich kritisieren willst" dazuzudenken war anscheinend zu viel verlangt. Naja, wundert mich nicht.