ich bin gerade dabei, das Buch "Modernes C++ Design" zu lesen und bin auf manche sehr interessante Dinge gestoßen. Zum Beispiel auf den Typ-Selector:

template <bool flag, typename T, typename U>
struct Select {
    typedef T Result;
};

template <typename T, typename U>
struct Select<false, T, U> {
    typedef U Result;
};

Ich hoffe mal, er versteht sich von selbst.
In meinem Code gibt es jede Menge Funktionen, die je nach Erfolg einen bool mit bzw. true oder false zurückgeben. Macht es in diesem Beispiel Sinn, den Returntyp der Methode machWas in ein

typename Select<CheckingPolicy::Checked, bool, void>::Result

umzuschreiben?

#include <iostream>

struct Check {
    enum { Checked = true };

    bool valid(void* ptr) const
    { return ptr; }
};

struct NoCheck {
    enum { Checked = false };

    bool valid(void*) const
    { return true; }
};

template <class CheckingPolicy>
class Foo : public CheckingPolicy {
public:

    bool machWas(void* ptr) {
        if (!CheckingPolicy::valid(ptr))
            return false;
        return true;
    }
};

Foo<Check> f;
void* ptr = &f;

// -------------------------------------------
int main () {
    std::cout << f.machWas(NULL /* oder ptr zum Testen */) << std::endl;
    return 0;
}

Wenn Foo nicht gecheckt werden soll, muss auch kein bool zurückgegeben werden. Beschleunigt das oder ist das alles nur überflüssig/behindernd?

Danke!

Bei Modern C++ Design musst du manchmal aufpassen: Es gibt sehr viele interessante Dinge, aber vieles ist nicht für den 1:1 Praxisgebrauch geeignet. Zu viele Policies machen Code unnötig komplex, zudem kann man nicht immer alles als Template schreiben. Manchmal sind auch dynamisch-polymorphe Strategien sinnvoller als statische Policies.

Das nur als genereller Hinweis, was soll machWas() denn tun?

Ansonsten dürfte die Funktion sich auch weiter ändern als du das mit Templates umsetzen kannst, wenn du den Rückgabetyp zu void umbiegen solltest.

Mir ging es nicht darum, ob die Klasse sinnvoll ist und ob sie sinnvolle Methoden hat.

Generell gilt ja:
Wenn man die Checks, z.B. wenn es um Pointer geht, weglässt, dann erhöht sich doch normalerweise die Geschwindigkeit. Angenommen, Foo wäre eine SmartPointer-Klasse, bei der man durch Policies wählen kann, ob der Pointer bei einer Zuweisung geprüft wird oder nicht. Bei einem Programmabschnitt, indem massehaft SmartPointer erstellt und zugewiesen werden, macht es Sinn, die SmartPointer nicht prüfen zu lassen, da man mit einer großen Zunahme an Ausführungsgeschwindigkeit rechnen kann. Die Zuweisungsmethode gibt einen bool zurück, der den Erfolg der Ausführung verrät. Wenn ich jetzt aber einen NotChecked-SmartPointer habe, macht es keinen Sinn, wenn die Zuweisungsmethode trotzdem noch einen bool zurückgibt.

Nochmal zu CStoll:
Ich würde aber keinen ungeprüften SmartPtr anlegen und dann wissen wollen, ob die Zuweisung ohne Probleme verlief.

Und Loki::SmartPtr ist mit seinen fünf Policies massiv overengineered, trotzdem kann man die Klasse für einfache Spezialfälle nicht gebrauchen (Beispiel siehe hier). Ich habe mir für die Fälle, in denen std::unique_ptr und std::shared_ptr nicht geeignet sind, eigene Smart-Pointer geschrieben. Das betrifft vor allem Implementierungen mit Deep-Copy-Semantik.

Das ist mir klar.
Wer sagt denn, ob ich Checken will? glGetIntegerv kann nicht wegoptimiert werden.

Klar, die Funktion kannst du nicht optimieren - aber im ungecheckten Ablauf mußt du sie auch nicht aufrufen, wenn du sie nicht benötigst.

Also macht es dann an der Stelle Sinn, ein CheckingPolicy zu verwenden.

Wenn es nur darum geht, Programmierfehler zu finden, nein. Ich sehe dein Problem wirklich nicht. Es ist ganz einfach:

• Für zeitintensive Überprüfungen zu Debugging-Zwecken, die keinen Einfluss auf die Semantik des Programms haben, nimmst du assert . Im Release-Modus sind alle Assertions ausgeschaltet, du hast also keinen Overhead.
• Sonst... nimmst du nicht assert

bool CheckedAssign(SmartPtr& dest, const SmartPtr& source);

schreiben.

P.S. Noch was:

allestester schrieb:

Die Zuweisungsmethode gibt einen bool zurück, der den Erfolg der Ausführung verrät. Wenn ich jetzt aber einen NotChecked-SmartPointer habe, macht es keinen Sinn, wenn die Zuweisungsmethode trotzdem noch einen bool zurückgibt.

Meinst du damit den SmartPtr::operator= ? Der sollte nicht bool , sondern SmartPtr& zurückgeben...

Einige meiner Klassen benutzen OpenGL. Das Checken lässt sich also nicht durch ein einfaches assert() erledigen, sondern der untersuchte Wert muss mit z.B. glGetIntegerv ermittelt werden.

Ich werf mal das Stichwort Exceptions in den Raum...

@dot:
Ich benutze nicht gerne Exceptions. Ich finde sie zu unhandlich.

Schau dir vielleicht den Artikel zu modernem Exceptionhandling an, er erklärt die Thematik wirklich gut.

@dot:
Ich benutze nicht gerne Exceptions. Ich finde sie zu unhandlich.

Sry, aber daraus kann man eigentlich nur schließen dass du sie nicht verstanden hast

Siehe was Nexus sagt

P.S. Noch was:

allestester schrieb:

Die Zuweisungsmethode gibt einen bool zurück, der den Erfolg der Ausführung verrät. Wenn ich jetzt aber einen NotChecked-SmartPointer habe, macht es keinen Sinn, wenn die Zuweisungsmethode trotzdem noch einen bool zurückgibt.

Meinst du damit den SmartPtr::operator= ? Der sollte nicht bool , sondern SmartPtr& zurückgeben...

Falls das schon erklärt wurde sorry, aber: was für ein Smart-Pointer ist das denn, dass der Zuweisungsoperator fehlschlagen kann?

Selbst wenn es z.B. um eine Never-Null Garantie geht, kann der Zuweisungsoperator nicht fehlschlagen, sofern
a) man im Konstruktor überprüft ob ein Nullpointer übergeben wurde, und falls ja, brav abort()ed oder eine Exception wirft und
b) der Zuweisungsoperator nicht mit rohen Zeigern funktioniert

Dinge die (auf Grund von Laufzeitfehlern) fehlschlagen können, haben IMO in einem Smart-Pointer nix verloren. Und Dinge die nur auf Grund von Programmierfehlern fehlschlagen können, würde ich mit assert() oder abort() behandeln.