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...

operator "" (double) für Doubleliterale
operator "" (char für Stringliterale

Auß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.

template<char...> SomeType operator "" BenutzerSuffix();

"123"BenutzerSuffix   // ruft operator"" BenutzerSuffix<'1','2','3'>() auf

Dieser 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-Literal

wobei 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'>()
// etc

aufgefasst 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 enutzerSuffix

Vielleicht ist diese Ambiguität von Standardisierungskomitee übersehen worden. Zumindest finde ich nichts zur Auflösung im FCD.

kk

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 enutzerSuffix

Vielleicht 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.