Benutzerdefinierte Stringliterale

cooky451

314159265358979 schrieb:

Leider ist im Standard kein einziger solcher operator drin. Ich hätte schon wieder sooooo viele Ideen, was man da alles machen könnte.

Ja? Dann lass doch mal sehen. Bei mir sind das nur ganz neue Ideen zur Code-Confusion.

314159265358979

Ich würde wohl einen Header <units> einführen, der eine Klasse zum typsicheren Arbeiten mit Einheiten enthält. (Dich z.B. daran hindert, meter und kilogramm zu addieren.) Da könnte man schon für jede SI-Basiseinheit einen solchen operator einführen.

SeppJ

Ich warte ja auf (3.14159265358979).cos()

Ethon

Ist doch sicher perfekt um schöne Fallen einzubauen.

Laut Wikipedia ist es in C++11 bzw. wird enthalten sein (ist noch in Zukunftsform geschrieben). Sicher, dass es nicht drin ist?

314159265358979

Sind drin.

314159265358979

Das tolle an den Operatoren ist ja, dass man auch andere Zeichen als die aus dem Standard-Zeichensatz verwenden kann, beispielsweise π.

pumuckl

314159265358979 schrieb:

Das tolle an den Operatoren ist ja, dass man auch andere Zeichen als die aus dem Standard-Zeichensatz verwenden kann, beispielsweise π.

Jein. Der operator darf irgendein identifier sein. Die dürfen aus den bekannten digits, non-digits, universal-character-names und weiteren, implementation-defined characters bestehen. Wobei es allerdings auch wieder implementation-defined ist, welche "physical source file character" in einen universal-character-name übersetzt werden.

Es gibt also drei Möglichkeiten:
a) Die Implementation setzt laut [lex.phases, 1] Π beim Parsen in einen \uXXXXXXXX um (d.h. man darf Π auch in string-literalen und character-literalen benutzen)
b) Die Implementation nimmt die genannte Umwandlung nicht vor, erlaubt Π aber als Teil eine identifiers ([lex.name]). D.h. es darf in string/char-Literalen nicht vorkommen, wohl aber als Identifier und damit auch als Literal-Suffix
c) Die Implementation tut auch das nicht, dann ist Π als Literalsuffix nicht erlaubt.

So oder so ist es also implementation defined, man darfs aber genauso für Funktionsnamen, Variablennamen, Klassennamen usw. benutzen - wenns die implementation erlaubt.

Weiss jemand, wie man Literale (z.B. lit) in einem Namensraum Ns verwenden kann ohne using namespace Ns; zu machen? Etwa 42Ns::lit!?

ipsec

litterist schrieb:

Weiss jemand, wie man Literale (z.B. lit) in einem Namensraum Ns verwenden kann ohne using namespace Ns;

Spontan würde ich using Ns::lit vermuten.

ipsec schrieb:

Spontan würde ich using Ns::lit vermuten.

Dachte ich auch, kanns aber nicht überprüfen. Trotzdem ist das etwas umständlich. Es leitet sogar zur These, dass nur Literale im globalen Namensraum sinnvoll einsetzbar sind, woraus folgt, dass sie von Bibliotheken nicht verwendet werden sollten.

pumuckl

litterist schrieb:

Weiss jemand, wie man Literale (z.B. lit) in einem Namensraum Ns verwenden kann ohne using namespace Ns; zu machen? Etwa 42Ns::lit!?

Vermutlich läuft das aufs gleiche bei raus wie bei allen anderen Operatoren. Die kann man in einem fremden NS benutzen wenn
a) per ADL in den richtigen Namespace geschaut wird, oder
b) per using-Direktive der ganze Namespace oder
c) nur der Operator bekannt gemacht wird. (z.B. using Ns::operator+)

a) greift hier nie, weil die Argumente builtin-Literale sind
b) willst du nicht
c)

using Ns::operator "" lit;