throw()

Tc++H

Wozu throw da ist, ist mir schon klar, aber wozu soll das sein:

/*
 * copied_ptr - simple copy-on-create/assign pointer.
 *
 * Note: If the actual object pointed to belongs to a derived class,
 * then copied_ptr will not create a copy of the derived class object,
 * but a new base class object.
 * If you want to use a polymorphic copy-on-assign pointer, use
 * cloned_ptr.
 */

#ifndef COPIED_PTR_H
#define COPIED_PTR_H

/* For ANSI-challenged compilers, you may want to #define explicit */

template <class X> class copied_ptr
{
public:
    typedef X element_type;

    explicit copied_ptr(X* p = 0) throw()       : itsPtr(p) {}
    ~copied_ptr()                               {delete itsPtr;}
    copied_ptr(const copied_ptr& r)             {copy(r.get());}
    copied_ptr& operator=(const copied_ptr& r)
    {
        if (this != &r) {
            delete itsPtr;
            copy(r);
        }
        return *this;
    }

    X& operator*()  const throw()               {return *itsPtr;}
    X* operator->() const throw()               {return itsPtr;}
    X* get()        const throw()               {return itsPtr;}

private:
    X* itsPtr;
    void copy(const copied_ptr& r)  {itsPtr = r.itsPtr ? new X(*r.itsPtr) : 0;}
};

#endif // COPIED_PTR_H

hinter jedem Operator, bzw. jeder Funktion steht ein throw.

volkard

http://tutorial.schornboeck.net/exception_spec.htm

Simon2

volkard schrieb:

http://tutorial.schornboeck.net/exception_spec.htm

Ergänzend sollte man sagen, dass leider einige Compiler nicht einmal feststellen, wenn eine Verletzung der exception specification vorliegt und stattdessen einfach die exception fliegen lassen und NICHT terminate aufrufen.

Ergo: exception specifications sind bestenfalls "Schmuck am Nachthemd" , schlimmstenfalls Verwirrungsstifter, die Fehlersuche und Wartung eher erschweren als vereinfachen.

[java-sachen gelöscht]

Gruß,

Simon2.

evilissimo

[antworten auf java-sachen gelöscht]

Simon2

EDIT: OK, dann nochmal ohne "Java-Sachen"

evilissimo schrieb:

...
Das ist nicht Problem der Sprache, sondern des Compilers und des Programmierers der Klasse.

BR
Vinzenz

Neee, es ist das Problem der Sprache, dass sie spezifiziert,
a) dass eine ex-spec erst zur Laufzeit ausgewertet wird. Ist eigentlich Blödsinn, da man diese genauso auswerten kann wie die "const-correctness" .... aber bei ex-specs wurde diese Konzession gemacht, um die "C-Anbindung" zu unterstützen; ich hätte mir da lieber eine Erweiterung à la " extern "C" " gewünscht.

b) Nicht besonders hilfreich ist, dass ein globales terminate() aufgerufen wird, dass keine Chance mehr hat, festzustellen, wer wann wo welche exception geworfen hat. Damit kann man eigentlich in dieser Methode nichts sinnvolles mehr machen. Da hilft es auch nicht, dass man terminate() ersetzen kann ... weil auch die eigene Funktion nicht hellsehen kann. Alternativ kann man natürlich versuchen, für jeden Aufruf, der eine ex-spec-Verletzung verursachen könnte, eine eigene terminate()-Funktion zu setzen .... aber das ist (abgesehen von Laufzeitnachteilen) ein Wartungs-Armageddon.

Muß man bei der Verwendung von exc-spec einfach bedenken.

Gruß,

Simon2.

volkard

in erinnerung an http://www.c-plusplus.net/forum/viewtopic-var-t-is-158841-and-start-is-0.html trenne ich hier mal frühzeitig sachthema und sprachenkrieg.

Simon2

volkard schrieb:

...sprachenkrieg.

OK, den wollte ich wirklich nicht anzetteln und habe noch nicht genug Erfahrung hier, um so etwas (in Art und Ausmaß) vorauszusehen

Bleiben wir also einfach bei unserer schönen Sprache C++, den um die geht's hier ...

Gruß,

Simon2.

P.S.: In besagtem Thread habe ich übrigens gar nicht den Eindruck, dass es sich um einen "interlingualen Krieg" handelt, sondern mehr um "Dewhurst::C++Gotchas#12::Adolescent Behaviour" und andere Eitelkeiten. Die "Hauptkampfhandlungen" werden ja zwischen C++ern ausgetragen.....