C++ Template spezialisation einer member function

[Da D. (dieter)]

Moin zusammen,

Normalerweise kann man ja eine Memberfunktion, die eine const referrence 
als parameter bekommt, problemlos mit einem non-const object aufrufen, 
da der cast non-const -> const immer möglich ist:

class ClassA
{
    void f(const ClassB& b);
}
...

ClassA a;
ClassB b;
a.f(b);  //b ist nicht const, macht aber nichts

So weit so gut. Wenn ich aber jetzt ein template aus f mache gibts ein 
Problem:

class ClassA
{
    template<typename T>
    void f(T& t) {...};
    template<>
    void f(const ClassB& b) {...};
}
...

ClassA a;
ClassB b;
a.f(b);  //b ist nicht const, und deswegen funktioniert die spezialisierung nicht :-/

Jetzt wird die Funktion für ClassB plötzlich nicht mehr aufgerufen, 
sondern die generische. So weit ich weiß wird doch eigentlich immer die 
am weitesten spezialisiere Funktion, die auf den übergebenen Typ passt, 
aufgerufen. Und passen tut es, denn ohne template gehts ja auch.

Mach ich irgendetwas falsch? Oder muss ich jetzt echt für "ClassB&" und 
"const ClassB&" seperate spezialisierungen machen? Oder gibts nen 
besseren Weg?

[Sebastian V. (sebi_s)]

Ja so ist das nunmal mit den C++ Overload Regeln. Kein Cast ist besser 
als ein const hinzufügen also kriegst du die Funktion mit dem Template. 
Eine einfache Möglichkeit das zu umgehen ist bei der Template Variante 
auch ein const hinzuzufügen (falls der Code der Funktion das 
ermöglicht). Dann erfordern beiden Funktionen den gleichen Cast aber die 
Variante ohne Template "gewinnt".

[Karl H. (kbuchegg)]

Da D. schrieb:


> aufgerufen. Und passen tut es, denn ohne template gehts ja auch.

Auch ohne Template würde bei

class ClassA
{
     void f(ClassB& b);
     void f(const ClassB& b);
}

die non-const Version bevorzugt werden.

Man kann sich das auch so merken: die const-Version wird nur dann 
benutzt, wenn es unbedingt sein muss, weil das Argument des Aufrufers 
selber const ist.

ein 'const' in einer Argumentschnittstelle ist so zu lesen: Die Funktion 
macht die Zusicherung, dass es das übergebene Argument nicht verändern 
wird.

Logischerweise passt ein derartiges const natürlich auch dann, wenn der 
Aufrufer ein Objekt hat, dass veränderbar wäre. Macht ja nix, wenn die 
Funktion dieses Objekt nicht verändern will. Sie könnte - aber wenn sie 
es nicht tut, ist es auch gut.
Aber umgekehrt geht das natürlich nicht. Wenn der Aufrufer ein Objekt 
hat, dass nicht verändert werden darf, dann muss die Funktion auch die 
entsprechende Zusicherung machen.

>
> Mach ich irgendetwas falsch? Oder muss ich jetzt echt für "ClassB&" und
> "const ClassB&" seperate spezialisierungen machen? Oder gibts nen
> besseren Weg?

Kommt auf die Funktion an. Wenn f das Objekt sowieso nicht verändern 
will, dann kann man natürlich in der nicht-const Version das const 
dazucasten und die const-Version aufrufen. Macht man das alles inline, 
dann kostet das auch keine Laufzeit.

[Da D. (dieter)]

Sebastian V. schrieb:
> Eine einfache Möglichkeit das zu umgehen ist bei der Template Variante
> auch ein const hinzuzufügen

Gute Idee. Aber leider muss die template Variante das Objekt verändern 
können. Bzw. ich kann nur für die Spezialisierung zusichern, dass nichts 
verändert wird.

Karl H. schrieb:
> Auch ohne Template würde bei class ClassA
> die non-const Version bevorzugt werden.

Hm, ja, das erklärt es wohl. Der cast auf const wird nur gemacht, wenn 
keine direkt passende Funktion gefunden wird. Und ein template, bei dem 
alles erlaubt ist, passt halt für alles...

Karl H. schrieb:
> Wenn f das Objekt sowieso nicht verändern
> will, dann kann man natürlich in der nicht-const Version das const
> dazucasten und die const-Version aufrufen.

Ja, so mach ich es dann wohl. In der spezialisierten Variante muss ich 
das Objekt nicht verändern. Also rufe ich, um Codeduplikation zu 
vermeiden,in der nicht-const Version die const Version auf.

Danke euch!

[Karl H. (kbuchegg)]

Da D. schrieb:

> Also rufe ich, um Codeduplikation zu
> vermeiden,

Genau darum gehts.

Wenn man den Cast vermeiden will, geht immer noch

class ClassA
{
...
     void f(ClassB& b)           { f_impl( b ); }
     void f(const ClassB& b)     { f_impl( b ); }

private:
     void f_impl( const ClassB& b );
};

[Sebastian V. (sebi_s)]

Vielleicht etwas übertrieben aber man kann auch mit SFINAE was zaubern 
um die Template Version für ClassB zu deaktivieren:

class ClassA
{
    template<typename T, typename = std::enable_if_t<!std::is_same<T, ClassB>::value>>
    void f(T& t) {}
    
    void f(const ClassB& b) {}
};

Wenn noch mehr Spezialisierungen dazu kommen ist das aber auch nicht 
gerade so schön.

[apr (Gast)]

Fehlt da nicht ein std::decay?

[Da D. (dieter)]

Sebastian V. schrieb:
> man kann auch mit SFINAE was zaubern

Genial :) So funktioniert es auch. Wieder was gelernt. Danke!

apr schrieb:
> Fehlt da nicht ein std::decay?

In meinem speziellen Fall geht es tatsächlich auch ohne. Für "const 
ClassB" ist ja schon eine Spezialisierung vorhanden. Für "ClassB" greift 
dann die Bedingung in std::is_same.