Constness bei Funktionsparametern und Typsynthese
-
Hallo,
ich habe folgenden Code (stark vereinfacht):
typedef boost::function_types::parameter_types<void (int const)>::type parameters; typedef boost::mpl::at_c<parameters, 0>::type argument; //... std::cout << std::booalpha << boost::is_const<argument>::value << std::endl; //auf MSVC9 false, erwartet true std::cout << typeid(argument).name() << std::endl; //auf MSVC9 int erwartet const intAuf MSVC9 bekomme ich kommentierten Ergebnisse. Ich würde allerdings erwarten, dass
is_const 'true'liefert bzw. dastypeid 'const int'liefert. Ändere ich die Signatur invoid (int const &)bekomme ich wie erwartet dasconstmitgeliefert (nach Entfernung der Referenz).
Habe ich da irgendwie einen Denkfehler drin? Ist das ein Bug?
-
Vielleicht optimiert der Compiler das unnötige const einfach weg, wenn es sich nicht um eine Referenz/einen Pointer handelt.
-
der mit dem const tanzt schrieb:
Vielleicht optimiert der Compiler das unnötige const einfach weg, wenn es sich nicht um eine Referenz/einen Pointer handelt.
Dann würde folgendes compilierbar sein:
void f(int const a) { a = 10; }ist es aber, wie erwartet, nicht.
-
top-level cv-Qualifikationen eines Funktionsparameters sind niemals Teil des Funktionstyps (8.3.5/5).
-
camper schrieb:
top-level cv-Qualifikationen eines Funktionsparameters sind niemals Teil des Funktionstyps (8.3.5/5).
Wo liest Du das denn raus?
ISO/IEC 14882:2003 8.3.5/5 schrieb:
[Example: the declaration
int fseek(FILE*, long, int);
declares a function taking three arguments of the specified types, and returning int (7.1.5). ]
-
Es dürfte 8.3.5/3 gemeint sein.
-
Bashar schrieb:
Es dürfte 8.3.5/3 gemeint sein.
Wer lesen kann (ich anscheinend nicht) ist klar im Vorteil.
-
Ich bezog mich auf n3290. 8.3.5/3 ist der entsprechende Absatz für C++03.
Quellenangaben beziehen sich bei mir grundsätzlich auf den neuen Standard, wenn nichts anderes gesagt wird.
-
Sorry camper, das war mir eigentlich klar, ich hab mich dann aber von diesem Fast-Treffer in C++98 blenden lassen.