wieso gibt es in c++ kein finally?

[hä???]

Fellhuhn schrieb:

RAll?

Google: RAll

Rall Caravaning - Das HYMER-Zentrum
Rall präsentiert Ihnen die Welt des Caravaning. Es erwartet Sie das komplette Angebot an Hymer Reisemobilen und Wohnwagen sowie eine Riesenauswahl an ...
www.rall.de/ - 13k - Im Cache - Ähnliche Seiten

Günther Rall – Wikipedia
a.D. Günther Rall zu Besuch im „Deutsch-Kanadischen Luftwaffenmuseum e.V.“ am 26. November 2004 im Baden-Airpark von Rheinmünster-Söllingen ...
de.wikipedia.org/wiki/Günther_Rall - 36k - Im Cache - Ähnliche Seiten

Ted Rall Online
- [ Diese Seite übersetzen ]
Ted Rall, America's hardest-hitting editorial cartoonist for Universal Press Syndicate, is an award-winning commentator who also works as an illustrator, ...
www.rall.com/ - 6k - Im Cache - Ähnliche Seiten

W. Rall Baumschulen e.K. | Home
W. Rall Baumschulen e. K. Sulzwiesenstraße 1 72800 Eningen unter Achalm Telefon 07121 / 98 85 98-0 Telefax 07121 / 98 85 98-85 info@w-rall.de ...
www.w-rall.de/ - 6k - Im Cache - Ähnliche Seiten

Welcome to Rall Guitars & Tools
Riesige Sammlung mit vielen Photos zur Gitarren Reparatur, Restaurierung, Neubau, Technik, Wartung. Interessante Erfahrungsberichte und Anleitungen zum ...
www.rall-online.net/ - 4k - Im Cache - Ähnliche Seiten
...

[Konrad Rudolph]

Copy&Paste will gelernt sein.

http://www.google.com/search?hl=en&q=RAII&btnI

[Artchi]

LOL! http://www.google.com/search?hl=de&q=raii&btnG=Suche&lr=

[hä???]

Konrad Rudolph schrieb:

Copy&Paste will gelernt sein.

Wohl eher nicht Copy&Paste, wenn er RALL schreibt.

[Konrad Rudolph]

hä??? schrieb:

Konrad Rudolph schrieb:

Copy&Paste will gelernt sein.

Wohl eher nicht Copy&Paste, wenn er RALL schreibt.

Eben. Er hat's offensichtlich noch nicht gelernt.

[exception-freak]

hustbaer schrieb:

Ich wäre _für_ ein finally in C++.

naja, aber wenn man mit c++ exceptions noch nicht mal 'nen nullpointer-access oder eine miese rechenoperation wie 'division durch 0' abfangen kann, macht das auch nicht viel sinn.

[Simon2]

exception-freak schrieb:

hustbaer schrieb:

Ich wäre _für_ ein finally in C++.

naja, aber wenn man mit c++ exceptions noch nicht mal 'nen nullpointer-access oder eine miese rechenoperation wie 'division durch 0' abfangen kann, macht das auch nicht viel sinn.

Wieso ? Kann man doch. Man muss nur sein Programm in einer passenden VM laufen lassen ...

Gruß,

Simon2.

[hä???]

exception-freak schrieb:

hustbaer schrieb:

Ich wäre _für_ ein finally in C++.

naja, aber wenn man mit c++ exceptions noch nicht mal 'nen nullpointer-access oder eine miese rechenoperation wie 'division durch 0' abfangen kann, macht das auch nicht viel sinn.

Wenn man könnte, was würde dann finally neues bringen, was du sonst nicht kannst?

[absturz-freak]

hä??? schrieb:

Wenn man könnte, was würde dann finally neues bringen, was du sonst nicht kannst?

na, RAII funzt z.b. nicht mehr bei einem (int)0 = ...;
das programm kackt gnadenlos ab. ein finally könnte dann noch ein paar aufräumarbeiten verrichten. aber wie gesagt, es liegt ja nicht am fehlenden finally, sondern an den exceptions, die zu 'high-levelig' sind.

[hä???]

absturz-freak schrieb:

hä??? schrieb:

Wenn man könnte, was würde dann finally neues bringen, was du sonst nicht kannst?

na, RAII funzt z.b. nicht mehr bei einem (int)0 = ...;
das programm kackt gnadenlos ab. ein finally könnte dann noch ein paar aufräumarbeiten verrichten.

Jeder Destruktor dann aber auch

aber wie gesagt, es liegt ja nicht am fehlenden finally, sondern an den exceptions, die zu 'high-levelig' sind.

eben

C++ hat doch eigentlich ein eingebautes finally bei jedem "}" (wenn man mal die Heap Sachen außer Acht lässt, da muss man dann auto_ptr oder sowas nehmen). Das "C++ finally" ruft dann die Destruktoren auf. Alles was du einmal in C++ in nen Destruktor schreibst, musst du in allen finallys immer wieder hinschreiben -> code duplication

[Gast]

Im Borland C++ Builder gibt es das __finally. Und ehrlich gesagt möchte ich nicht mehr darauf verzichten.
Ich empfinde es als sehr angenehm, Aufräumarbeiten nur im __finally-Block machen zu können und nicht im catch-Block für den Fehlerfall und zusätzlich am Funktionsende den, meist zu 95 Prozent indentischen, Code nochmal hinkopieren zu müssen.

[Konrad Rudolph]

Joe_M. schrieb:

Ich empfinde es als sehr angenehm, Aufräumarbeiten nur im __finally-Block machen zu können und nicht im catch-Block für den Fehlerfall und zusätzlich am Funktionsende den, meist zu 95 Prozent indentischen, Code nochmal hinkopieren zu müssen.

Du hast RAII verstanden.

[Braunstein]

@Joe
Ich habe das ursprünglich auch so gehandhabt (nutze ebenfalls BCB). Mittlerweise nutze ich aber durchgängig Smartpointer und passende Destruktoren, so dass finally nicht mehr nötig ist.

[asc]

Konrad Rudolph schrieb:

Du hast RAII verstanden.

Das trifft leider heutzutage noch immer auf viele C++ Entwickler zu, gerade wenn diese vor dem C++98 Standard angefangen haben, aber auch wenn sie von eben jenen gelernt haben. (etwas überzogen) So wie es noch immer Firmen gibt bei denen böse gesprochen alles Verboten ist, das der Chefentwickler nicht versteht...

cu André

[hustbaer]

Ja, RAII ist toll.
Finally wäre trotzdem nett.

[groovemaster]

hustbaer schrieb:

C++ ist doch sonst nicht so zimperlich wenns darum geht mehrere Wege anzubieten um dasselbe Ziel zu erreichen.

Naja, das kommt eher durch die Abwärtskompatibilität. finally ist ein strukturierter Ansatz, das passt nicht wirklich zu OO.

exception-freak schrieb:

naja, aber wenn man mit c++ exceptions noch nicht mal 'nen nullpointer-access oder eine miese rechenoperation wie 'division durch 0' abfangen kann, macht das auch nicht viel sinn.

Genau das wäre imo brauchbarer für den neuen Standard als finally. Sowas lässt sich mit C++ bisher leider nur plattformspezifisch umsetzen.

[*john 0]

hustbaer schrieb:

Finally wäre trotzdem nett.

Finally ist in C++ total überflüssig.

[Tachyon]

groovemaster schrieb:

exception-freak schrieb:

naja, aber wenn man mit c++ exceptions noch nicht mal 'nen nullpointer-access oder eine miese rechenoperation wie 'division durch 0' abfangen kann, macht das auch nicht viel sinn.

Genau das wäre imo brauchbarer für den neuen Standard als finally. Sowas lässt sich mit C++ bisher leider nur plattformspezifisch umsetzen.

Hmm,
Null-Pointer-Exceptions lassen sich simpel mit einer "Checked Access" Funtion durchführen, oder alternativ mit einer entsprechenden Template-Klasse die das etwas schöner macht:

#include <iostream>
#include <exception>

template<typename T>
T* checked_access(T* ptr)
{
    if(!ptr)
    {
        throw std::runtime_error("Zero pointer exception");
    }
    return ptr;
}

int main()
{

    int* a = NULL;

    try
    {
        *checked_access(a) = 3;
    }
    catch(...)
    {
        //...
    }

    return 0;
};

Bei einer Division ist es immer sinnvoller, den Divisor auf 0 zu prüfen, als solche Fehler über ein Laufzeitfehlersystem einmal quer durchs Betriebssystem zu schießen.
Beides ist Plattformunabhängig...

[*john 0]

Das Problem ist sowohl bei Null-Pointer wie Div durch 0, daß man das jeweils von Hand vor dem Zugriff überprüfen muß. Es wäre schöner, wenn die Laufzeitumgebung automatisch eine entsprechende Exception werfen würde.

[asc]

~john schrieb:

Es wäre schöner, wenn die Laufzeitumgebung automatisch eine entsprechende Exception werfen würde.

Bitte behaltet immer in Hinterkopf das C++ auch das Ziel hat effizient und schnell zu sein. Bei C++ wird nicht ohne grund einiges von Laufzeitentscheidungen in die Hand des Entwicklers gelegt. Wenn ich z.B. ausschließen kann das ich über die Indexe eines vectors zugreife, ist eine Prüfung eine unnötige Laufzeitbelastung. Ebenso wenn ich von vorne herein weiß das keine 0 in meinen Divisionen auftreten kann oder, oder, oder...

Man muss abwägen zwischen Sicherheit und Performance, C++ hat halt auch letzteres im Auge. Wobei übertriebene Sicherheit wiederum dazu führt das Entwickler Fehler teilweise garnicht betrachten.

cu André