wie gut kann der compiler hier optimieren



  • hallo

    da ich redunanten code nicht mag, schreibe ich bei projekten in etwa folgendes:

    class foo
    {
        ::std::string str;
    public:
        foo(::std::string const& str = "default")
            : str(str)
        {
        }
        ::std::string const& get_str() const
        {
            return this->str;
        }
        void set_str(::std::string const& str = foo().get_str())
        {
            this->str = str;
        }
    };
    

    also mir geht es darum die default-parameter allgemein verwalten zu können. wird jedoch - wenn man bei set_str keinen parameter angibt - wirklich eine neue instanz erstellt, dessen methode dann aufgerufen wird? oder kann das geschickt optimiert werden, dass ich keinen overhead habe im gegensatz zur mehtode, zwei mal "default" zu schreiben? ich möchte eigentlich keinen runtime overhead haben nur wegen sauberem code.

    gruss



  • Also Dein Code enthaelt sehr viel Redundanz. Wenn Du solche setter und getter hast, kannst Du den member gleich public machen. using vermeidet das staendige std:: Dasselbe viel kuerzer:

    using std::string;
    class foo
    {
    public:
        string str;
        foo(string const& str = "default")
            : str(str)
        {
        }
    };
    

    Und wenn die member schon public sind, geht auch

    using std::string
    struct foo
    {
        string str = "default"
    };
    


  • also mir geht es darum die default-parameter allgemein verwalten zu können.

    Ich persoenlich vermeide default-Parameter gaenzlich, der Uebersicht halber.

    nur wegen sauberem code

    Nun, default-Parameter sind fuer mich unsauber. Wenn der default-Variante zu 90% benutzt wird, dann sollte man sich ueberlegen warum die Methode ueberhaupt diesen Parameter hat. Wenn sie nur zu 10% benutzt wird, warum dann ueberhaupt einen default-Wert. Weiterhin sind Methodenaufrufe mit impliziten Parametern fuer mich persoenlich schlechter zu warten, beim Lesen von Code eben nicht alles dasteht.

    Zur Frage: Der Compiler kann optimieren, wird hoechstwahrscheinlich auch, muss aber nicht. Abhilfe fuer diese Unsicherheit schafft ein Blick in den generierten ASM-Code.



  • Hmm, ich habe eine setPixel Methode, in der ich ganz selten den Alphawert brauche, aber so gut wie immer R G B. Dort habe ich dann unsigned char a = 255 als Defaultwert, das fand ich schon praktisch.

    Warum sollte da zwei Methoden daraus machen?



  • Warum sollte da zwei Methoden daraus machen?

    Gegenfrage: Habe ich das vorgeschlagen? Man koennte auch einen Typ Color anbieten, der entsprechende Konstruktoren hat.



  • Ne, hast du nicht, aber auch wieder ein Objekt mehr, nur um einen Defaultwert zu sparen? Ist sicher eine Lösung und solch eine Colorklasse habe ich auch, aber ich wollte auch die Methode anbieten, die mit einzelnen Werten arbeiten kann und um dort nicht noch eine zusätzliche Methode ohne alpha machen zu müssen, griff ich dann auf den Defaultwert zurück.

    Na egal, macht halt jeder wie er will. Ich finde die Defaultwerte schon nützlich, aber ich bin auch C++ Anfänger.



  • knivil schrieb:

    Warum sollte da zwei Methoden daraus machen?

    Gegenfrage: Habe ich das vorgeschlagen? Man koennte auch einen Typ Color anbieten, der entsprechende Konstruktoren hat.

    Damit verlagerst du das Problem auch nur in den Konstruktor. Da du keine Defaultparameter verwendest, bist du zur Überladung gezwungen. Im Endeffekt hast du also doch zwei Methoden, nur um den Defaultparameter zu vermeiden.

    CppNeuland schrieb:

    Hmm, ich habe eine setPixel Methode, in der ich ganz selten den Alphawert brauche, aber so gut wie immer R G B. Dort habe ich dann unsigned char a = 255 als Defaultwert, das fand ich schon praktisch.

    Ist es auch, keine Frage. Problematisch wirds nur, wenn man beim Aufruf jeweils überlegen (oder sogar nachschauen) muss, wie nun der Wert aussieht, wenn man ihn weglässt. In diesem Fall schreibt man ihn lieber gleich hin.


Log in to reply