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 …
(gelöst) Sind no-op Konvertierungsoperatoren erlaubt?
- Krishty
- Establishment
- Beiträge: 8351
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
(gelöst) Sind no-op Konvertierungsoperatoren erlaubt?
Zuletzt geändert von Krishty am 07.04.2013, 17:19, insgesamt 1-mal geändert.
Re: Sind no-op Konvertierungsoperatoren erlaubt?
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
- Krishty
- Establishment
- Beiträge: 8351
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Sind no-op Konvertierungsoperatoren erlaubt?
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.
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.
- B.G.Michi
- Establishment
- Beiträge: 163
- Registriert: 07.03.2006, 20:38
- Alter Benutzername: B.G.Michi
- Kontaktdaten:
Re: Sind no-op Konvertierungsoperatoren erlaubt?
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)
(Edit: im zitierten §12.3.2 steht nix von Referenzen, sollte also passen)
- Krishty
- Establishment
- Beiträge: 8351
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Sind no-op Konvertierungsoperatoren erlaubt?
Großartig; danke! :)
Re: (gelöst) Sind no-op Konvertierungsoperatoren erlaubt?
Wieso machst du sowas überhaupt? Und wie kann man damit Kompilierzeit sparen?
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
- Krishty
- Establishment
- Beiträge: 8351
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: (gelöst) Sind no-op Konvertierungsoperatoren erlaubt?
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.)
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.)