typedef in Verbindung mit Forward-Deklarationen... + Stilfragen



  • Na ja, das Ding will halt eine Referenz auf einen Pointer. Er fragt ja nach TokenPtr, was Token* sein sollte.

    Die Konvertierung von Token* auf Token*& scheint demnach das Problem zu sein, was sich aber nur daraus ergibt, dass Token* und TokenPtr hier halt doch ein Unterschied ist.

    Was sich hinter TokenPtr anderes verstecken soll als Token*, weiß ich jetzt auch nicht. 🙂 Wenn ich nichts typedeffe, hab ich halt ständig soooo lange Funktionsrümpfe. Ich meine, das ist jetzt ja noch ok, aber wenn ich zwei- oder dreifach geschachtelte Templates habe, wird's ziemlich unleserlich. Der Standard verwendet doch auch viele typedefs und in verschiedenen professionellen Anwendungen werden doch auch derartige Konventionen genutzt, oder nicht?


  • Mod



  • </Exit> schrieb:

    1. Ich hätte lieber das hier genommen:
    const vector< Token* >& Lexer::Tokenize(std::string term)
    

    Finde ich persönlich einleuchtender als die typedef.

    Naja typedefs sind aus meiner sicht ganz klar zu bevorzugen, da diese die Software wartbaerer macht. Zumal es den Anwender nicht Interresiert was für ein Pointer verwendet wird es ist nur Interresant das ein pointer verwendet wird aber nicht ob dieser Intern ein roher Zeiger ist oder ein SmartPointer.
    Zum Thema Wartung, stell dir vor du möchtes plötzlich anstelle von deinen einfachen Zeigern SpmartPointer verwenden, weil es immer schwerer wird sich um die richtige freigabe der Daten zu kümmern. Ohne typedefs ist das ein großer Aufwand diese zu ersetzen, vorallem wenn deine Klasse nicht ganz klein und trivial ist und zudem noch abhängigkeiten mit anderen Klassen hat oder um außerhalb der Klasse mit dem Zeiger zu arbeiten. Im Fall von typedefs muss ich nur eine stelle im Quellcode ändern umd die Eigenschaften des Pointers zu ändern. Ohne tpyedefs muss ich die Textersetzung bemühen und hoffen das ich alle Pointer ersetzt hab.



  • Ja, genau, das waren auch meine Gedanken. Aber das Problem ist jetzt nach wie vor nicht gelöst 😞

    Ich kann das typedef auch nicht in der Funktionsdefinition nutzen, weil er mir sagt, dass das kein Typ ist (weil sich das typedef ja auf die Forward-Deklaration bezog und nicht auf den Typ der inkludierten Datei).



  • Kannst du mal ein kompilierbares Minimalbeispiel erstellen? Denn irgendwie passt die Fehlermeldung imo nicht ganz zum Code..

    2. Ja, siehe auch hier

    3. Ja. Nicht nur, dass es lesbarer werden kann, sondern eben auch besser wartbar.

    4. Variante a, da, wenn du jetzt wirklich etwas ändern solltest, dann würdest mit Variante b vom typedef nichts gewonnen haben.

    Zu 1 kann ich nur sagen, dass das mit Visual Studio funktioniert. Könnte aber theoretisch auch sein, dass da (obwohl Spracherweiterungen abgeschaltet sind) zugunsten des Lookups vom Standard abgewichen wird. (müsste ich auch zuerst nachschauen).



  • Wie schon mehrfach erläutert: Der Code passt zu dem Ding.

    TokenPtr ist hier nicht gleich Token* sondern gleich der Variante von Token, die nur der Forward-Deklaration entspricht. Das ist meine Einschätzung der Lage, weil die Ersetzung der Forward-Deklaration durch ein Include den Fehler behebt.

    Werde später/die Tage dann Mal ein kleines lauffähiges (oder halt eben nicht) Programm posten, aber eigentlich sollte das keine neuen Erkentnisse liefern.



  • GAMES1990 schrieb:

    Im Fall von typedefs muss ich nur eine stelle im Quellcode ändern umd die Eigenschaften des Pointers zu ändern. Ohne tpyedefs muss ich die Textersetzung bemühen und hoffen das ich alle Pointer ersetzt hab.

    Hm, ja seh ich ein... Kommt halt drauf an, was man für eine Anwendung hat 😉

    @Eisflamme:
    Musst du denn die Forward-Deklaration wirklich machen? Wenn du so viele Probleme hast, dann würde ich überlegen, es nicht komplett davor zu ziehen bzw. den Header von Token zu includieren.
    Oder spricht da was in deinem Projekt dagegen? (ich kenn's ja nicht 😃 )


  • Mod

    Eisflamme schrieb:

    Wie schon mehrfach erläutert: Der Code passt zu dem Ding.

    Aber es ist nicht das Ding, folglich kann niemand etwas nachvollziehen. Weil das so ist, haben wir ernsthafte Zweifel.

    // Token.hpp
    class Token
    {
    };
    
    //Lexer.hpp
    #include <vector>
    #include <string>
    using namespace std;
    class Token;
    
    class Lexer
    {
    public:
    	typedef Token* TokenPtr;
    
    private:
    	vector<TokenPtr> tokens_;
    
    public:
    	const vector<TokenPtr>& Tokenize(string term);
    };
    
    //Lexer.cpp
    #include "Lexer.hpp"
    #include "Token.hpp"
    
    const vector<Lexer::TokenPtr>& Lexer::Tokenize(std::string term)
    {
    	tokens_.push_back(new Token());
    	return tokens_;
    }
    

    Keine Probleme hier. Also: Poste Code, der hinreichend vollständig ist.



  • Eisflamme schrieb:

    Werde später/die Tage dann Mal ein kleines lauffähiges (oder halt eben nicht) Programm posten, aber eigentlich sollte das keine neuen Erkentnisse liefern.

    Doch, wird es. Entweder wir finden den Fehler oder können dir sagen, dass du einen Fehlerhaften Compiler hast.


  • Mod

    Möglicherweise erfolgt die Vorwärtsdeklaration von Token im echten Programm im falschen Namensraum. Das ist allerdings nur geraten.



  • Ahhh... Ok, das mit der Forwarddeklaration im falschen Namespace war sogar sehr gut geraten. 😃

    Und mein anderes Problem hing dann damit zusammen, dass ich wieder typename vergessen habe anzugeben. Ich code einfach zu selten 😞 Danke! 🙂



  • camper schrieb:

    Möglicherweise erfolgt die Vorwärtsdeklaration von Token im echten Programm im falschen Namensraum. Das ist allerdings nur geraten.

    Das war genau das, was ich gemeint habe, dass der Fehler nicht zum Code passt..



  • Ok, dann geb ich Dir auch da Recht. 🙂 Ich glaube, ich hatte vorher eine andere Fehlermeldung und hab die dann irgendwie damit vermischt. Keine Ahnung.



  • Eisflamme schrieb:

    Ok, dann geb ich Dir auch da Recht. 🙂 Ich glaube, ich hatte vorher eine andere Fehlermeldung und hab die dann irgendwie damit vermischt. Keine Ahnung.

    Merke: Wenn du Code postest dann nicht welchen der so ähnlich aussieht wie der der den Fehler produziert, sondern reduziere deinen Code und stelle sicher, dass der Fehler darin auch noch vorkommt. Siehe Link in meiner Singatur.



  • Ok, ihr habt völlig Recht, tut mir Leid. Werde es in Zukunft so wie in den Regeln beschrieben machen. 🙂 Danke für die Zeit und Hilfe.


Anmelden zum Antworten