[C++0x] Stringliterale & Templates
-
Guten Morgen,
ich habe vor kurzem im Zusammenhang mit der Definition von benutzerdefinierten Stringliteralen in C++0x folgendes Konstrukt gesehen:
template<char...> SomeType operator "" BenutzerSuffix(); "123"BenutzerSuffix // ruft operator"" BenutzerSuffix<'1','2','3'>() auf(siehe auch: http://en.wikipedia.org/wiki/C%2B%2B0x#User-defined_literals)
Meine Frage hierzu: Ist diese Art der "speziellen" Templateinstantiierung speziell für den operator "" vorgesehen oder lässt sich nun auch folgendes machen:
template<char ...> struct foo{ // }; foo<"abc"> bar;? Bisher konnte ich jedenfalls noch keinen Hinweis darauf entdecken, dass dies der Fall sein könnte...
-
Mich wundert diese Template-Schreibweise auch, allerdings muss man zuerst einmal sagen, dass dieses Beispiel in Wikipedia für numerale Datentypen wie float da steht!
Was mich konkret am Template wundert:
Wie werden die Daten übergeben?
-
operator "" steht für eine Literal ohne Type
operator "" (double) für Doubleliterale
operator "" (char
für StringliteraleAußerdem kann ich an mein Literal ein beliebiger Suffix angeben.
#pragma print(x) als Anweisung, dass der Compiler eine Ausgabe schreibt.
void operator "" _Out(char* literal) { #pragma print(literal) } void operator "" _Out(double literal) { #pragma print(literal) } int main() { "Hello World"_Out; // Hello World in Compileroutput 3.12145587788_Out; // 3.12145587788 in Compileroutput }Den Trick mit den Char Variadic template muss ich mir noch ansehen.
-
Matzer schrieb:
template<char...> SomeType operator "" BenutzerSuffix(); "123"BenutzerSuffix // ruft operator"" BenutzerSuffix<'1','2','3'>() aufDieser Operator passt nicht zu der Literal-Syntax. Das Literal ist ein sogenanntes "user defined string literal". Als solches kommen die über char... templatisierten Literal-Operatoren nicht in Frage. Die richtige Syntax für Deinen Operator ist diese hier:
SomeType a = 12345BenutzerSuffix; // benutzer-definiertes Integer-Literal SomeType b = 007BenutzerSuffix; // benutzer-definiertes Integer-Literal SomeType c = 0x333BenutzerSuffix; // benutzer-definiertes Integer-Literal SomeType d = 1.314BenutzerSuffix; // benutzer-definiertes Float-Literal SomeType e = 4.2e1BenutzerSuffix; // benutzer-definiertes Float-Literalwobei diese, sofern keine anderen Operatoren definiert wurden, als Aufrufe
operator""BenutzerSuffix<'1','2','3','4','5'>() operator""BenutzerSuffix<'0','0','7'>() operator""BenutzerSuffix<'0','x','3','3','3'>() // etcaufgefasst werden. Die anderen Operatoren (falls vorhanden) hätten allerdings höhere Priorität. Also, Wenn Du zB noch operator""BenutzerSuffix(double) deklariert hättest, dann würden die letzten beiden Literale diesen Operator aufrufen.
Dass die "rohen" Zeichen vor dem Suffix zu Template-Parametern übersetzt werden können, ist eine spezielle Regel bei der Literal-Syntax. Dein Beispiel mit foo<"123"> wird nicht funktionieren.
Allerdings frage ich mich gerade, was passiert, wenn ein benutzerdefinierter Suffix mit einem Zeichen anfängt, welches noch zu einem Integer- oder Float-Literal gehören könnte. ZB 0x333BenutzerSuffix. Das könnte man jetzt auf zwei Arten zerlegen:
0x333 BenutzerSuffix 0x333B enutzerSuffixVielleicht ist diese Ambiguität von Standardisierungskomitee übersehen worden. Zumindest finde ich nichts zur Auflösung im FCD.
kk
-
krümelkacker schrieb:
Allerdings frage ich mich gerade, was passiert, wenn ein benutzerdefinierter Suffix mit einem Zeichen anfängt, welches noch zu einem Integer- oder Float-Literal gehören könnte. ZB 0x333BenutzerSuffix. Das könnte man jetzt auf zwei Arten zerlegen:
0x333 BenutzerSuffix 0x333B enutzerSuffixVielleicht ist diese Ambiguität von Standardisierungskomitee übersehen worden. Zumindest finde ich nichts zur Auflösung im FCD.
N2747 sagt dazu:
[...] Any user-defined suffix starting with [A-Fa-f] has a potential conflict with hexidecimal notation. While the proposal defines away ambiguity (N2378 section 5 "Proposed Wording", modifying clause 13.5.8 over.literal, paragraph 0), that definition effectively means that suffixes intended for use with arbitrary integers must avoid more than 22% of the available suffix namespace. Some of these effectively prohibited suffixes would otherwise be the natural choice. The same applies to floating point values, e.g. "e" as electron charges, though to a lesser degree. [...]
Wie gesagt, ich sehe davon nichts im FCD. Vielleicht bin ich aber auch blind.