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

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.

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.

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

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.