F
@john-0 sagte in noexcept in library, wann und wo nutzen:
@Finnegan sagte in noexcept in library, wann und wo nutzen:
Ich denke in einer echten OOM-Situation wird man eine std::bad_alloc-Exception ohnehin kaum sinnvoll behandeln können. Ausser vielleicht mit einem sehr speziellen, auf diese Situation zugeschnittenen Handler.
Dank Memory Overcommitment wirst Du in einem echten OOM-Fall gar keine Exception sehen, da erst bei Zugriff auf die Pages das OS feststellt, dass es nicht mehr ausreichend RAM hat. Auf einem UNIX/Linux siehst Du da einen SegFault, und das Programm kann da gar nichts mehr machen. Was man darüber nur abfangen kann, sind unrealistisch große Speicheranforderungen, da gibt das OS noch eine negative Rückmeldung.
Ja, vielleicht noch durch vom System forcierte Speicher-Limits, oder wenn man eine Malloc-Implementierung verwendet, der man eine Obergrenze mitgeben kann. Eigentlich ein Argument mehr, dass man in dem Fall auch ein terminate() akzeptabel sein könnte. Schlechter als ein SegFault ist das nicht.
Sicher gibts auch Szenarios, wo man die Exceptions haben will, aber die Menge an Funktionen, die noexcept sein könnten, wenn bad_alloc wegfällt und fast überall z.B. bei std::move_if_noexcept gemoved werden kann ist nicht zu verachten.
Würde mich jedenfalls mal interessieren, was sich damit im Schnitt herausholen ließe. Besonders bei größerem Legacy-Code, der gar nichts noexcept deklariert und viel in Containerklassen herumschiebt. Zumindest wenn die Klassen überhaupt effizient gemoved werden können, z.B. mit vielen std::string oder std-Container Daten-Membern.