Suchergebnisse

Hi, ich hab nicht so viel Erfahrung mit Templates in C++, hab aber grade 'nen Einsatz dafür und bin mir nun an einer Stelle unsicher. Ich habe 'ne Klasse token, die einen mathematischen Token repräsentiert. Der Header sieht mal so aus (die Implementierung ist bisher noch nicht da): (Versteckter Text) Ich werde vermutlich noch auf std::string umsteigen, bin nur gerade mal so verblieben, obwohl ich vermutlich keine 2 Byte-Character brauche. Meine Klasse generic_token sieht so aus (Header): (Verste…

Soweit ich weiß, sollte man C-Style Casting in C++ doch nicht verwenden und auf static_cast<>, dynamic_cast etc. zurückgreifen, oder? Grüße

@jvbsl Danke. Von Template specialization hatte ich bisher noch nichts gehört. Hab's mir mal kurz auf der CppReference angeschaut und das scheint sowas zu sein, wie ich gesucht hatte. Das finde ich extrem nützlich, dass C++ sowas hat. @RodFromGermany Ich werde mich mal der Template specialization annehmen, da das die bessere Lösung scheint, als das Zeugs einfach zu casten, wenn man das architektonisch hier anders lösen kann. Und C-Casts wollte ich eigentlich auch vermeiden. Grüße

Zitat von Gonger96: „Mach den Destruktor von token mal virtuell, dann klappts.“Jo, aber ich denke Template Specializations erlauben es mir, das sauberer zu lösen, als mit irgendwelchen Casts rumzuhantieren, oder? Den Destruktor brauche ich ja eigentlich nicht, d.h. er würde leer bleiben. Zitat von Gonger96: „Ich würde dass mit dem token_type aber lassen bzw. einschränken“Das Problem ist, dass bspw. ein Operator genauso wie eine Funktion als generic_token<std::string> repräsentiert werden kann. F…

Stimmt, so habe ich noch gar nicht gedacht. Dann würde ich mir die ganzen Templates und Switches sparen und einfach die verschiedenen Tokens eindeutig zuordnen, die dann ausgewertet werden können. Die einzige Baustelle wäre dann token::read_str_token. Da ja im Voraus nicht bekannt ist, was das zurückgibt, müsste der Rückgabetyp halt generell erstmal token sein. Aber das ist ja egal, da evaluate ja vererbt wird und ich das einfach aufrufen kann, egal, was sich genau für eine Token- Unterklasse da…

Jetzt hast Du mich etwas verwirrt. Inwiefern steht das jetzt in Verbindung mit den verschiedenen Tokens und der Polymorphie? Das wäre ja nämlich eine generische Methode evaluate, die so für mehrere Typen implementiert wird. Allerdings bräuchte ich ja gar keine Templates mehr, wenn ich zwischen den einzelnen Token unterscheide, oder? Denn jeder Token hätte die dann, würde den Stack bekommen, seine Aufgabe erledigen und das Ergebnis auf den Stack pushen. Und dann verstehe ich ein paar Sachen in De…

Ah okay, Faulheit. Und das ist ein Funktionszeiger, ah, das klingt schon mal logischer. Danke dafür. Achso, daher meintest Du das mit token<>, oder? Also die Algorithmen über den Term laufen lassen und dann die verschiedenen Tokens, die gelesen wurden, in einer Liste halten, die dann durchlaufen und jeweils evaluieren. Dazu müsste ich ja evaluate einfach die jeweilige Value übergeben bzw. diese halt ermitteln. Allerdings kann ich ja bspw. keinen vector<token> machen, wenn dort ein Template dranh…

Verstehe. Das klingt mir aber etwas umständlich, ich würde das schon lieber etwas polymorph trennen. Grüße

Warum Monster-Methode? Grüße

Ja, im Moment. Aber ich möchte es ja auf verschiedene Klassen aufteilen, die das eigens implementieren. Grüße