Returntyp dynamisch ändern

Hallo,

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!

Nexus

Ich hätte jetzt wahrscheinlich assert(ptr) geschrieben, aber man kanns auch so wie du machen

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?

CStoll

Bei deinem Beispiel sehe ich nicht, wo man dort die Rückgabe weglassen könnte - du verwendest schließlich den Rückgabewert von machwas() im Hauptprogramm.

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.

Danke für die schnellen Antworten :).

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.

Sorry für Doppelpost, aber als Unregistrierter kann man ja seine Posts nicht bearbeiten.

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

Nexus

Wenn es nur um Geschwindigkeit geht – d.h. eine Prüfung wäre immer sinnvoll, aber manchmal zu langsam – würde ich wirklich assert() nehmen. Policies stehen nur zur Diskussion, wenn die Programmsemantik betroffen ist.

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.

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. Ein assert macht hier vermutlich keinen Sinn, da wahrscheinlich der Aufruf von glGetIntegerv am meisten Zeit braucht. Hier macht es doch Sinn, durch ein Policy festzulegen, ob gecheckt werden soll oder nicht, oder?

CStoll

Wieso sollte das ein Problem mit dem assert sein? Im Debug-Modus spielt die Zeit keine Rolle (und da du sowieso checken willst, ist dein Aufruf auch notwendig), im Release wird der assert()-Aufruf sowieso vom Präprozessor wegoptimiert.

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

CStoll

allestester schrieb:

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.

Nexus

allestester schrieb:

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

OpenGL Errors können auch außerhalb des Debuggings auftreten. Code, der bei mir auf dem PC läuft, muss nicht auf meinem Lappi laufen. Allein schon wegen der verschiedenen Hardware.

Nexus

Okay, Laufzeitfehler sind wieder ein anderes Thema als Programmierfehler. Dann kann so eine Policy Sinn machen, aber ich würds damit nicht übertreiben. Denk dran, dass du jede Policy in den Typen eingravierst und dadurch leicht verschiedene, inkompatible Template-Instanziierungen erzeugst. Wenn es nur darum geht, eine Zuweisung zu überprüfen, kannst du auch eine Funktion

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...

dot

allestester schrieb:

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...

@Nexus:
Okay, dann werde ich mir mal genauer überlegen, wo ich asserts anstatt Policies verwende. Vergiss mein Beispiel, das war mehr als schlecht

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

Nexus

Der grosse Vorteil von Exceptions besteht darin, dass du den Anwendercode frei von Fehlerbehandlung halten kannst. Du musst nicht jede Anweisung einzeln auf ihren Erfolg prüfen, ausserdem brauchst du den Status nicht umständlich über mehrere Funktionen hinweg hochzureichen.

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

dot

allestester# schrieb:

@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

Ich hab noch kein ganzes Buch über Exception-Handling gelesen, nur ein Kapitel eines Buches. Vielleicht sollte ich mich damit mal ein bisschen beschäftigen.

hustbaer

Nexus schrieb:

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.