ZFX + Developia

Hi,

Ist das hier standardkonform?

    struct Foo {

        operator Foo() const {
            return *this;
        }

    };

Visual C++ akzeptiert es, und es spart mir 7 % Kompilierzeit.

Aber ich bin misstrauisch weil es eher wie etwas aussieht, was jemand dem Compiler zu verbieten vergessen hat …

Für mich sieht das wie ein ganz normaler Cast-Operator aus. Oder übersehe ich da eine Kleinigkeit? Wenn nicht, dann habe ich das schon auf zig Compilern benutzt. Schau mal hier unter "Cast-Operatoren", nur um sicher zu gehen das ich nichts übersehen habe: http://de.wikibooks.org/wiki/C++-Progra ... Operatoren

Er ist insofern nicht normal, als dass er exakt zum selben Typ castet wie vorher – er ist schlicht überflüssig.

Es könnte ja sein, dass im C++-Standard irgendwo ein Wortlaut steht, der Konvertierungsoperatoren nur für andere Typen erlaubt … damit ein blöder Compiler nicht in einer Endlosrekursion landet oder der Programmierer merkt, dass er Scheiße baut, oder so.

Siehe auch hier. Du kannst ihn schon deklarieren aber es gibt eigentlich keine Möglichkeit ihn aufzurufen.
(Edit: im zitierten §12.3.2 steht nix von Referenzen, sollte also passen)

Großartig; danke! :)

Wieso machst du sowas überhaupt? Und wie kann man damit Kompilierzeit sparen?

Ich hatte bisher zwei Typen: ReadableRange<Foo> und ReadWritableRange<Foo>. Die beiden sind fast identisch; man handelt sich also entweder viel doppelten Quelltext ein oder eine komplexe Template-Hölle.

Eine große Hürde dabei, das durch eine einheitliche Klasse Range<Foo const> und Range<Foo> zu ersetzen, war, dass ich unbedingt eine Konvertierung von zweitem zu erstem benötige, möglichst implizit (so wie const Correctness nicht funktionieren würde, wenn man Foo nicht zu Foo const konvertieren könnte).

Verkacktes C++ hat keine eingebauten Datentypen für sowas. Aber dafür so gut wie völlig unbrauchbare C-Arrays. Bah.

Da ein no-op-Konvertierungsoperator – wie ich nun weiß – erlaubt ist, klatsche ich einfach einen Konvertierungsoperator zu Range<Foo const> rein und gut ist. Weil fast alle meine Algorithmen auf Ranges aufbauen, ist ein großer Teil meines Master-#includes entfallen, und das wirkt sich spürbar positiv auf die Kompilierzeit aus.

    1>Build succeeded.
    1>
    1>Time Elapsed 00:00:00.83
    ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

(Mittlerweile benötigt ein komplettes Neukompilieren der Engine plus Initialisierung bis ins Spiel weniger als eine Sekunde.)