Wozu braucht man Reflection?
-
Shade Of Mine schrieb:
Aber dynamic_cast ist zB auch runtime reflection - nur eben als Sprachmittel eingebaut.
In computer science, reflection is the ability of a computer program to examine (see type introspection) and modify the structure and behavior (specifically the values, meta-data, properties and functions) of an object at runtime.
-
Zeus:
Ehrlich gesagt verstehe ich bei Deinen Posts die Zusammenhänge generell nicht. Du sagst "Das ist Schwachsinn" oder "Das ist Unsinn", sagst aber nicht, worauf es sich bezieht und an der Begründung nach dem ersten Satz kann ich nicht ablesen, wo da der Zusammenhang zum Satz davor besteht. Die Grammatikfehler helfen mir da auch nicht weiter. Vielleicht hat Shade of Mine Dich deswegen missverstanden?Mal unabhängig von euren Wortschlachten. Die Java-Reflection ist doch einfach Mal ausgeprägter als die in C++, egal wie man es nennt.
In C++ kann ich mir eben nicht die Attribute/Methoden einer Klasse auflisten lassen. Ich kann prüfen, ob foo() existiert, aber nicht eine Liste erhalten. Genau das wäre aber für eine allgemeine Serialization-Funktionalität notwendig. Und über XML-Dateien Abhängigkeiten einzupflanzen, die dann Dependency Injection (Diskussionsfall für sich, ob man das braucht) erlauben und viele weitergehende Mechanismen nutzen, weben das von "omg..." zitierte Feature des "modify class at runtime" an.
-
Reflection ist ein Java-Müll den keiner braucht, aber wenn es in C++ irgendwann kommt, ist es das beste wo gibt.
-
Zusammengefasst schrieb:
Reflection ist ein Java-Müll den keiner braucht, aber wenn es in C++ irgendwann kommt, ist es das beste wo gibt.
Ich denke, dass Compiletime Reflection viel wichtiger ist als Runtime Reflection. Damit kann ich mir naemlich memberweise Vergleichsoperatoren oder Serialisierungsroutinen automatisch generieren lassen. Oder wie waere es mit einer GUI-View, die fuer meine Klasse generiert wird.
-
Ich denke, dass Runtime Reflection den Grundprinzipien einer statisch stark typisierten Sprache widerspricht...
-
Kellerautomat schrieb:
Ich denke, dass Compiletime Reflection viel wichtiger ist als Runtime Reflection. Damit kann ich mir naemlich memberweise Vergleichsoperatoren oder Serialisierungsroutinen automatisch generieren lassen. Oder wie waere es mit einer GUI-View, die fuer meine Klasse generiert wird.
Geht alles mit Runtime Reflection.
-
ja und... schrieb:
Kellerautomat schrieb:
Ich denke, dass Compiletime Reflection viel wichtiger ist als Runtime Reflection. Damit kann ich mir naemlich memberweise Vergleichsoperatoren oder Serialisierungsroutinen automatisch generieren lassen. Oder wie waere es mit einer GUI-View, die fuer meine Klasse generiert wird.
Geht alles mit Runtime Reflection.
Jau, ganz toll. Dann fragst du jedes einzelne Objekt, wie es aufgebaut ist, oder wie?
Es geht darum, zur Compilezeit bereits Code generieren zu koennen, sodass gar kein Overhead mehr vorhanden ist.
-
Kellerautomat schrieb:
ja und... schrieb:
Kellerautomat schrieb:
Ich denke, dass Compiletime Reflection viel wichtiger ist als Runtime Reflection. Damit kann ich mir naemlich memberweise Vergleichsoperatoren oder Serialisierungsroutinen automatisch generieren lassen. Oder wie waere es mit einer GUI-View, die fuer meine Klasse generiert wird.
Geht alles mit Runtime Reflection.
Jau, ganz toll. Dann fragst du jedes einzelne Objekt, wie es aufgebaut ist, oder wie?
Da braucht man schon nen Quantencomputer um so ne GUI aufzubauen.
-
reflection is slow as fuck
-
english guest schrieb:
reflection is slow as fuck
like Java
-
Reflection setzt man ja auch nicht in performancekritischem Code ein...
-
Eisflamme schrieb:
Reflection setzt man ja auch nicht in performancekritischem Code ein...
like Java
-
Das einzige was ich ueber Compiletime Reflection hier gelernt habe, ist der Post von Shade, wo es gleichgesetzt wird mit Compiletime Metaprogramming. Wenn dem so ist, warum wird dann hier so ein Fass aufgemacht? Ist dem so?
@Kellerautomat: Nun, ich kenne Scala nicht, aber dafuer Scheme sehr gut, insbesondere das Makrosystem. Damit damit kann ich zur Kompilezeit und Laufzeit Code generieren. Meinst du sowas?
-
Ich würde mir das Template-System von C++ kombiniert mit dem Code-Generator von D wünschen. Wo passive Code-Generierung (aka. templates) hilft, finde ich templates ja gut, aber wo man mit templates auf Compile-Time-Rekursionen ausweichen muss, gehen sie mir streckenweise doch sehr stark auf den Sack.
Geil finde ich auch die Jungens, die eine variable Liste von Template-Parametern so in Typ-Listen und MPL-Compile-Time-Suche aufdröseln, dass man die Paramater in beliebiger Reihenfolge angeben kann. Keine Sau braucht sowas, aber die Compiler und unbedarften Programmierer schwitzen über Jahrzehnte an diesen Konstrukten... Einfach lächerlich...
Keine Ahnung, was das jetzt mit dem Thema zu tun hat, aber bei Templates gehts mit mir immer los.
-
C++ Template Metaprogrammierung hat nur bedingt was mit Compiletime Reflection zu tun. Type Traits gehoeren natuerlich dazu, aber die sind dann Compiler-generiert, bzw. werden durch constexpr Funktionen ersetzt. Es gab mal ein Proposal, das in die richtige Richtung geht: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
Man kann Code zur Compilezeit ausfuehren (aka constexpr) und Code injecten (fehlt noch). Zudem kann man identifier zusammenbauen wie Strings.
-
D-teilweise-Gutfinder schrieb:
Geil finde ich auch die Jungens, die eine variable Liste von Template-Parametern so in Typ-Listen und MPL-Compile-Time-Suche aufdröseln, dass man die Paramater in beliebiger Reihenfolge angeben kann. Keine Sau braucht sowas, aber die Compiler und unbedarften Programmierer schwitzen über Jahrzehnte an diesen Konstrukten... Einfach lächerlich...
Natürlich, das ist dermaßen unwichtig, dass das Sprachmittel dazu zu einem der der größten neuen Features von C++11 wurde...;)
-
Kellerautomat schrieb:
C++ Template Metaprogrammierung hat nur bedingt was mit Compiletime Reflection zu tun. Type Traits gehoeren natuerlich dazu, aber die sind dann Compiler-generiert, bzw. werden durch constexpr Funktionen ersetzt. Es gab mal ein Proposal, das in die richtige Richtung geht: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
Man kann Code zur Compilezeit ausfuehren (aka constexpr) und Code injecten (fehlt noch). Zudem kann man identifier zusammenbauen wie Strings.Ich muss wohl zu blöd sein um dem sinn zu erkennen. Jeden Punkt wird mit C++14 abbildbar werden. Was heute fehlt ist die C++ Templatelib für Reflection.
Ich bin pessimistisch. Ein Vorschlag aus dem Jahre 2003, der nicht als Proposalreport niedergeschrieben ist und außerdem noch von eine Nicht-Compilerfraktion stammt.
-
dot schrieb:
D-teilweise-Gutfinder schrieb:
Geil finde ich auch die Jungens, die eine variable Liste von Template-Parametern so in Typ-Listen und MPL-Compile-Time-Suche aufdröseln, dass man die Paramater in beliebiger Reihenfolge angeben kann. Keine Sau braucht sowas, aber die Compiler und unbedarften Programmierer schwitzen über Jahrzehnte an diesen Konstrukten... Einfach lächerlich...
Natürlich, das ist dermaßen unwichtig, dass das Sprachmittel dazu zu einem der der größten neuen Features von C++11 wurde...;)
Ich habe nichts gegen Variadics gesagt, die man für vernünftige Code-Generatoren nunmal braucht, wenn man eben nur templates zur Hand hat, statt einer vernünftigen Code-Generier-Sprache.
Mit Typ-Listen meinte ich überhaupt nichts in die Richtung Variadics, sondern soetwas wie boost::mpl::vector und darin dann nach Typ-Argumenten mit boost::mpl::find_first oder sowetwas fischen, nur damit man die Sachen in einer beliebigen Reihenfolge angeben kann.
-
Man kann Code zur Compilezeit ausfuehren (aka constexpr) und Code injecten (fehlt noch). Zudem kann man identifier zusammenbauen wie Strings
Also ein Makrosystem wie in Lisp oder Scheme ...
