Ich habe mich jetzt auch an einen gesetzt, aber viel besser ist er nicht geworden: http://codepad.org/4zBw8d5f

Aktuell kompiliert es auch nur der Clang 3.3 (oder höher, habe das allerdings nicht getestet). GCC 4.9 steigt wegen einem falschen Feldindex aus - wie er da abkommt ist mir unklar.

Zwar ist die Rekursionstiefe gesunken, Programme mit einer Code(!)länge von mehr als 256 oder Schleifen benötigen bei Clang aber eine höhere Instantiierungstiefe als Flag (Clang meckert bei 256).

Dann habe ich den Thread tatsächlich noch einmal ausgegraben, und siehe da:

camper schrieb:

Ich habe eine Idee wie man das Ganze 1000mal effektiver machen kann (kein Scherz, damit wären dann auch kompliziertere Sachen machbar). Dummerweise unterstützt g++ noch keine constexpr Literale als statische Member, deshalb muss die Implementation noch ein bisschen warten.

Leider war ihm noch nicht langweilig genug.

Falls er sich noch an die Idee erinnert, dann wäre das interessant.

Mir fällt eine andere Variante ein, die Rekursion stark zu reduzieren: Gespaltene Auswertung für interpreter .
Also zuerst die eine Hälfte auswerten, dann die andere mit den Ergebnissen aus Hälfte 1.
Nun kann man leider nicht Schleifen in der Mitte spalten, daher klappt kein einfaches split_at . Man könnte natürlich alles zwischen den Schleifen spalten, und alles darin demselben Prozess hinterziehen.
Aber das würde mir jetzt zu viel Arbeit abverlangen.

Daher: Was meinte camper mit constexpr-Literalen? Das hört sich interessant an. UDLs*? Die können aber nicht als Member auftreten, nur im namespace-scope...

Btw: Clang ! Komplett Bugfrei. Bei GCC 4.9 (Snapshot vom 9. September) kam ich schnell an die Grenzen. Clang ist viel besser als erwartet, Fehlermeldungen sind auch sehr nett. Ich wusste nie, warum es permanent hochgepriesen wird...

* Das findet man über Google! User-Defined Literal. Kann man natürlich constexpr deklarieren, ist schließlich eine (mehr oder weniger gewöhnliche) Funktion.

template<typename CharT, CharT... str>
const_string<str...> operator "" _static(); //Edit: Man sollte natürlich direkt die verarbeitende Klasse als Rückgabetyp definieren - irgendeinen Interpreter o.ä.

Und per decltype den Typ bekommen.
Im aktuellen C++14-Draft ist aber leider derartiges nicht enthalten... obwohl es sehr sinnvoll ist...

template<typename CharT, CharT... str>
auto operator "" _foo();

Oder geht es dir um etwas anderes? Bin nicht sicher ob ich dich richtig verstanden habe...

EDIT: decltype(auto) -> auto

#define STRING(str) decltype( str##_static )

STRING("abc") // wird zu const_string<'a', 'b', 'c'>

Und dann wird einfach der Compiler den String in ein Parameter-Pack umwandeln. Super, oder?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html

• schrieb:

Nein, der Punkt ist ja, dass ich dann folgendes Makro schreiben kann:

#define STRING(str) decltype( str##_static )

STRING("abc") // wird zu const_string<'a', 'b', 'c'>

Und dann wird einfach der Compiler den String in ein Parameter-Pack umwandeln. Super, oder?

OK, verstehe.

Nur was bringt dir das?
Du kannst ja gleich vom UDL-Operator den fertigen Interpreter zurückgeben lassen.

Du kannst ja gleich vom UDL-Operator den fertigen Interpreter zurückgeben lassen.

Was meinst du genau? Ohne das Proposal sind UDLs nicht wirklich hilfreich, denn dann kann eine Operatorfunktion nur so aussehen:

Rueckgabetyp operator "" ( char const* ptr, std::size_t len )

Und was bringt mir das? Oder was meinst du?

(Mit "fertigen Interpreter zurückgeben" meinte ich, dass man das Parameterpack stattdessen an den Interpreter gibt. Das Parameterpack muss aber erstmal da sein...)

camper schrieb:

Ich habe eine Idee wie man das Ganze 1000mal effektiver machen kann (kein Scherz, damit wären dann auch kompliziertere Sachen machbar). Dummerweise unterstützt g++ noch keine constexpr Literale als statische Member, deshalb muss die Implementation noch ein bisschen warten.

Leider war ihm noch nicht langweilig genug.

Ich habe weiter hinten dann mal eine zweite Version gepostet, die die Ideen die ich damals hatte einigermaßen umsetzt. Allerdings war ich zu optimistisch, wass die Compilertechnologie angeht. Diese zweite Version benötigt tatsächlich deutlich weniger Speicher zum Compilieren, ist allerdings gleichzeitig um Größenordnungen langsamer (etwas über einer Stunde statt ein paar Sekunden - mit 99-bottles-code aus dem Netz), was primär daran liegen dürfte, dass der Compiler sich das Ergebnis einer Überladungsauflösung (der Prozess ist ja relativ teuer, noch etwas mahr als die Auswahl der richtigen Spezialisierung bei partiell spezialisierten Klassentemplates) nicht zu merken scheint.
Die Sache mit den Literalen war sowieso ein Missverständniss. Damals nahm ich noch an, die Templateform für solche Operatoren wäre auch bei Stringliteralen möglich. Eine praktisch meist ausreichende Lösung über Makros ist nicht allzu kompliziert - Sone hat bestimmt fertigen Code dafür.

Sone hat bestimmt fertigen Code dafür.

Ich bin Sone.

Und ja, den Code habe ich schon längst.

template<char ... args>
	using const_string = value_list<char, args...>;

	#define SPLIT_1(s, x) ( x < sizeof(s) ? s[x] : '\0' )
	#define SPLIT_4(s, x)    SPLIT_1  (s, x), SPLIT_1  (s, x+1)  , SPLIT_1  (s, x+2)  , SPLIT_1  (s, x+3)
	#define SPLIT_16(s, x)   SPLIT_4  (s, x), SPLIT_4  (s, x+4)  , SPLIT_4  (s, x+8)  , SPLIT_4  (s, x+12)
	#define SPLIT_64(s, x)   SPLIT_16 (s, x), SPLIT_16 (s, x+16) , SPLIT_16 (s, x+32) , SPLIT_16 (s, x+48)
	#define SPLIT_256(s, x)  SPLIT_64 (s, x), SPLIT_64 (s, x+64) , SPLIT_64 (s, x+128 , SPLIT_64 (s, x+194)
	#define SPLIT_1024(s, x) SPLIT_256(s, x), SPLIT_256(s, x+256), SPLIT_256(s, x+512), SPLIT_256(s, x+768)

	#define STRING_IMPL(str, n) rtrim<const_string<SPLIT_##n(str, 0)>, '\0'>::type

	#define STRING(str) STRING_IMPL(str, 64)
	#define STRING_256(str) STRING_IMPL(str, 256)
	#define STRING_1024(str) STRING_IMPL(str, 1024)

Wobei rtrim den String dann abschneidet. Findet sich alles in VTMPL.

Ich habe weiter hinten dann mal eine zweite Version gepostet, die die Ideen die ich damals hatte einigermaßen umsetzt.

Gut, habe ich nicht gesehen.