Template vernachlässigt const (warum?)

7

Weiß jemand, warum das kompiliert?

%Vor%

Ich kompiliere mit GCC 4.4. Warum lässt es mich das überhaupt kompilieren? Sollte es keinen Fehler geben, dass ich einer nichtkonstanten Referenz keine const-Referenz zuordnen kann?

    
Gabriel 07.11.2012, 16:05
quelle

4 Antworten

2

Damit der Code das tut, was er tun soll, müsste er lesen:

%Vor%

mit dem hinzugefügten "Feature", dass andere Typen in const-Referenzen umgewandelt werden, wenn sie zum Erstellen von FrontBackBuffer verwendet werden.

Das ist jetzt nicht perfekt. Dies verhindert, dass temporäre Argumente für FrontBackBuffer verschoben werden, und übergibt sogar kleine, billig zu kopierende Typen (wie char ) als Referenz anstatt als Wert. Es gibt Standard-C ++ 0x-Techniken, um dies zu tun, die ein bisschen schwierig zu schreiben sind, wenn Sie sich interessieren.

    
Yakk 07.11.2012, 16:24
quelle
13

Wenn T int& ist, dann ist der Typ const T nicht const int& , sondern int & const . Die ungültige oberste Ebene const für eine Referenz wird in den Templatesubstitutionen und typedef-Ergebnissen ignoriert.

Wenn andererseits T const int ist, dann ist T& const int&

    
Armen Tsirunyan 07.11.2012 16:11
quelle
5

Wenn TypeBufferFront int& ist, entspricht const TBufferTypeFront int& const , wobei const während der Vorlagensubstitution ignoriert wird, da alle Referenzen konstant sind, auch wenn sie nicht darauf verweisen.

Wenn Sie also mit int& instanziiert haben, ist Ihr Konstruktor effektiv FrontBackBuffer(int&, int&) , was wie angegeben funktioniert.

Dies ist ein Beispiel dafür, warum viele Leute T const anstelle von const T verwenden, um deutlicher zu machen, wie die Substitution stattfindet, und ihnen erlaubt, die cv-Qualifiers von rechts nach links zu lesen.

    
Dave S 07.11.2012 16:11
quelle
0

FrontBackBuffer::m_Front ist vom Typ TBufferTypeFront , was in Ihrer Template-Instanziierung in int& übersetzt wird. Es ist nichts falsch mit der Zuordnung zu int& .

    
Oswald 07.11.2012 16:11
quelle