Zusatz: Wenn nicht nur Leerzeichen sondern auch noch durch -> und * getrennt werden darf schaffe ich 10.

Viel Spaß beim ausprobieren.

Meine Lösung: http://ideone.com/z9vDak

compl compl compl compl compl compl /* usw. */ 0;

final und override sind keine Schlüsselwörter.

compl compl compl compl compl compl /* usw. */ 0;

Ich musste erstmal schauen was compl sein soll... Für mich ist das gar kein "echtes" Keyword. Ich würde compl durch sizeof tauschen.

Zählt das auch?

static_cast<int>(static_cast<int>(static_cast<int>(static_cast<int>(true))));

Sinn macht dieser Thread wohl nur, wenn man sich auf möglichst viele verschiedene Schlüssewörter beschränkt.

template <typename T> struct foo;
template <typename T> struct bar
{
    explicit inline virtual constexpr operator const volatile unsigned long int() const volatile noexcept try
    {
        if(true);
        else do return throw this xor nullptr and sizeof true or false bitand compl not new volatile signed long int bitor typename decltype
        (foo<T>::bar)::bar(); while(false);
    }
    catch (...)
    {
    }
};

Die Illuminati sind schuld.

//start

davor und

//end

danach.

Erst dann kann man sinnvoll vergleichen.

Außerdem zwei Klassen:

Klasse A: In der heftigen Zeile sind Sonderzeichen, Klammern, Operatorzeichen und eben alles so erlaubt. Auch wiederholte keywords, die werden dann aber nur einmal gezählt.

Klasse B: In der heftigen Zeile sind NUR Schlüsselwörter durch je ein Leerzeichen getrennt erlaubt, keine Doppelnennungen.

Für die B-Klasse melöde ich mal mich und Arcoth an.

Speziell für Klasse A könnte das nen Unterschied machen.

@camper: Teste deinen Code mal. Eine constexpr Funktion darf nicht als virtual definiert werden ([dcl.constexpr]/(3.1)).

ok, hab nur mit gcc getestet. Dann eben bloss eine Deklaration

struct baz
{
    explicit inline virtual constexpr operator const volatile unsigned long int() const volatile noexcept = 0;
};

Arcoth schrieb:

Im Übrigen sind xor usw. keine keywords.

Zitat?

Sie werden in lex.key aufgezählt und genügen wohl auch der (rekursiven) Definition im ersten Paragrafen (unconditionally treated as keywords).

Interessanterweise definiert Anhang A diese Kategorie nicht (sie wird allerdings wohl auch nirgendwo gebraucht).

Im Übrigen habe ich mich an die Definition des ersten Posts gehalten (enthaltehn in verlinkter Liste).

@volkard
Dürfen Keywords wiederholt werden (und werden dann bloss nicht mehrfach gezählt), oder darf jedes Keyword in der bewerteten Zeile max. 1x vorkommen?

Speziell für Klasse A könnte das nen Unterschied machen.

Bei A ja, Wiederholungen erlaubt (und nur einmal gezählt), dort isses ist eh recht formfrei.

Bei B nein, Wiederholungen nicht erlaubt, das würde zu viel der Eleganz rauben.

hustbaer schrieb:

@volkard
Dürfen Keywords wiederholt werden (und werden dann bloss nicht mehrfach gezählt), oder darf jedes Keyword in der bewerteten Zeile max. 1x vorkommen?

Speziell für Klasse A könnte das nen Unterschied machen.

Bei A ja, Wiederholungen erlaubt (und nur einmal gezählt), dort isses ist eh recht formfrei.

Bei B nein, Wiederholungen nicht erlaubt, das würde zu viel der Eleganz rauben.

Klasse A ist zu frei. Ein ganzes Programm passt in eine Zeile und kann sicher jedes Schlüsselwort verwenden. Zumindest Semikolons sollten wohl ausgeschlossen werden. Und mit Wiederholen kann beliebig rekursiv deklariert werden

#define x template<
#define y >class
//start
x x x x x x x x x x x x x x x x x x x x int y y y y y y y y y y y y y y y y y y y y
//end
foo;
int main();

//start
#define blub int short long double float char signed unsigned template class struct typename for while if switch case do return const mutable volatile ...
//end

oder halt

#define NIX(x)
NIX(
//start
int short long double float char signed unsigned template class struct typename for while if switch case do return const mutable volatile ...
//end
)

Arcoth schrieb:

@camper: Teste deinen Code mal. Eine constexpr Funktion darf nicht als virtual definiert werden ([dcl.constexpr]/(3.1)).

ok, hab nur mit gcc getestet. Dann eben bloss eine Deklaration

struct baz
{
    explicit inline virtual constexpr operator const volatile unsigned long int() const volatile noexcept = 0;
};

Das ist nach wie vor Quatsch, und die Tatsache, dass es nicht vom zitierten Paragraphen behandelt wird, ein Defekt.

Arcoth schrieb:

Im Übrigen sind xor usw. keine keywords.

Zitat?

Sie sind punctuators. Siehe auch [lex.operators].

camper schrieb:

Arcoth schrieb:

@camper: Teste deinen Code mal. Eine constexpr Funktion darf nicht als virtual definiert werden ([dcl.constexpr]/(3.1)).

ok, hab nur mit gcc getestet. Dann eben bloss eine Deklaration

struct baz
{
    explicit inline virtual constexpr operator const volatile unsigned long int() const volatile noexcept = 0;
};

Das ist nach wie vor Quatsch, und die Tatsache, dass es nicht vom zitierten Paragraphen behandelt wird, ein Defekt.

Natürlich ist es Quatsch. Aber wieso sollte das eine Rolle spielen?

Arcoth schrieb:

Arcoth schrieb:

Im Übrigen sind xor usw. keine keywords.

Zitat?

Sie sind punctuators. Siehe auch [lex.operators].

Ja und? Schließt sich das gegenseitig aus? new und delete sind bei dir auch keine Schlüsselwörter?

Arcoth schrieb:

camper schrieb:

Arcoth schrieb:

@camper: Teste deinen Code mal. Eine constexpr Funktion darf nicht als virtual definiert werden ([dcl.constexpr]/(3.1)).

ok, hab nur mit gcc getestet. Dann eben bloss eine Deklaration

struct baz
{
    explicit inline virtual constexpr operator const volatile unsigned long int() const volatile noexcept = 0;
};

Das ist nach wie vor Quatsch, und die Tatsache, dass es nicht vom zitierten Paragraphen behandelt wird, ein Defekt.

Natürlich ist es Quatsch.

Edit²: Dein Code ist ill-formed, NDR:

[dcl.constexpr]/5 schrieb:

For a constexpr function or constexpr constructor that is neither defaulted nor a template, if no argument values exist such that an invocation of the function or constructor could be an evaluated subexpression of a core constant expression (5.20), or, for a constructor, a constant initializer for some object (3.6.2), the program is ill-formed; no diagnostic required.

Damit führe ich gerade mit 10.

Ja und? Schließt sich das gegenseitig aus?

Ja, anscheinend. Du musst sonst die folgende Notiz erklären:

[ Note: Some white space is required to separate otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic characters. — end note ]

Du musst auch erklären, was es mit der folgenden Diskrepanz auf sich hat:

After all replacements due to macro expansion and evaluations of defined-macro-expressions and has-include-expressions have been performed, **all remaining identifiers and keywords¹⁴⁷, except for true and false , are replaced with the pp-number 0 **, and then each preprocessing token is converted into a token.

147. An alternative token (2.5) is not an identifier, even when its spelling consists entirely of letters and underscores. Therefore it is not subject to this replacement.

... oder du hast dich einfach auf die umgangssprachliche Bedeutung von keyword bezogen, nämlich ein intrinsisch reservierter Bezeichner?

int main() {if (0); else do extern constexpr const volatile unsigned long int operator+(struct A); while (0);}

camper schrieb:

Arcoth schrieb:

camper schrieb:

Arcoth schrieb:

@camper: Teste deinen Code mal. Eine constexpr Funktion darf nicht als virtual definiert werden ([dcl.constexpr]/(3.1)).

ok, hab nur mit gcc getestet. Dann eben bloss eine Deklaration

struct baz
{
    explicit inline virtual constexpr operator const volatile unsigned long int() const volatile noexcept = 0;
};

Das ist nach wie vor Quatsch, und die Tatsache, dass es nicht vom zitierten Paragraphen behandelt wird, ein Defekt.

Natürlich ist es Quatsch.

Edit²: Dein Code ist ill-formed, NDR:

[dcl.constexpr]/5 schrieb:

For a constexpr function or constexpr constructor that is neither defaulted nor a template, if no argument values exist such that an invocation of the function or constructor could be an evaluated subexpression of a core constant expression (5.20), or, for a constructor, a constant initializer for some object (3.6.2), the program is ill-formed; no diagnostic required.

Damit führe ich gerade mit 10.

Die Anwendung dieser Regel ist ja wohl völlig daneben, da keine Funktionsdefinition existiert. Andernfalls wäre jedes Programm, dass constexpr-Funktionen bloss deklariert abder nicht definiert (und auch nicht verwendet) ill-formed.

Arcoth schrieb:

Ja und? Schließt sich das gegenseitig aus?

Ja, anscheinend. Du musst sonst die folgende Notiz erklären:

[ Note: Some white space is required to separate otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic characters. — end note ]

Warum? Als Hüter des Standards weisst du am besten, dass solche Bemerkungen keinen normativen Charakter haben.

Arcoth schrieb:

Du musst auch erklären, was es mit der folgenden Diskrepanz auf sich hat:

After all replacements due to macro expansion and evaluations of defined-macro-expressions and has-include-expressions have been performed, **all remaining identifiers and keywords¹⁴⁷, except for true and false , are replaced with the pp-number 0 **, and then each preprocessing token is converted into a token.

147. An alternative token (2.5) is not an identifier, even when its spelling consists entirely of letters and underscores. Therefore it is not subject to this replacement.

Wo ist der Widerspruch? Widerum hat die Fußnote keine eigenständige Bedeutung, das ist nur Ausfluss dessen was wir schon wissen (2.5, die betreffenden Token fallen in die preprocessing-op-or-punc Kategorie, sind somit keine Identifier, können somit nicht Makronamen sein, und werden folglich an dieser Stelle auch nicht ersetzt - wie auch new und delete nicht). Wir vergessen mal dass es Implementationen in der Praxis damit oft nicht so genau nehmen.
Nimmt man es genau, findet sich hier ein Widerspruch zwischen 2.5 und 2.7:
Wenn identifier und preprocessing-op-or-punc disjunkte Kategorien sind, wie kann es dann sein, dass new und delete sowohl in Tabelle 4 (=identfier, die Keywords sind) als auch der Definition von preprocessing-op-or-punc auftauchen?
2.5/1 ist auch problematisch:

Each preprocessing token that is converted to a token (2.7) shall have the lexical form of a keyword, an identifier, a literal, an operator, or a punctuator.

keyword ist in dieser Aufzählung ja wohl redundant: es gibt keine Keywords, die nicht die lexikalische Form von identifier haben.

Oder vielleicht hat der Standard auch keine einheitliche Definition von "Keyword"; in A.1 z.B. wird plötzlich von kontext-dependent keywords gesprochen.

Arcoth schrieb:

... oder du hast dich einfach auf die umgangssprachliche Bedeutung von keyword bezogen, nämlich ein intrinsisch reservierter Bezeichner?

Selbstverständlich. Das war in dem Kontext ja wohl auch nicht anders zu erwarten - nicht zuletzt eben deshalb, weil der Threadstarter klar spezifiziert hat, was er unter Keyword verstanden haben will. Deine Erbsenzählerei ist daher unangebracht und peinlich.

Die Anwendung dieser Regel ist ja wohl völlig daneben, da keine Funktionsdefinition existiert. Andernfalls wäre jedes Programm, dass constexpr-Funktionen bloss deklariert abder nicht definiert (und auch nicht verwendet) ill-formed.

Unsinn. Die Tatsache, dass die Funktion gar nicht erst definiert oder overriden werden kann, ist ausschlaggebend (und das ist auch offensichtlich das, worauf ich mich bezog, und nicht auf eine direkte Verletzung der ODR).

Warum? Als Hüter des Standards weisst du am besten, dass solche Bemerkungen keinen normativen Charakter haben.

Nein, aber sie drücken Intention aus (was du als Hüter des Standards am besten weisst). Die Autoren dieser Notiz waren höchstwahrscheinlich auch im Entwicklungsprozess von Klausel 2 involviert, was Aufschluss über die richtige Interpretation git. Dass alternative tokens containing alphabetic characters in solch expliziter Form erwähnt werden, macht wohl etwas deutlich.

Wo ist der Widerspruch? ....

Einen Widerspruch gab es nicht. Worauf ich mit dem Zitat hinaus wollte: Keywords werden aufgezählt; alternative tokens sind nicht inbegriffen. => Alternative tokens sind keine keywords, und der Unterschied kann beobachtet werden.

#if void // Ok
#if and  // Nicht Ok (aus gutem Grund)

Wenn identifier und preprocessing-op-or-punc disjunkte Kategorien sind

"Identifier" wird merkwürdig vom Standard gehandhabt (ich habe erst neulich einen DR dazu abgeschickt). Offensichtlich sind einige der preprocessing-op-or-puncs lexikalische identifier (also wie in [lex.name] beschrieben), aber sie sind keine identifier Token.

wie kann es dann sein, dass new und delete sowohl in Tabelle 4 (=identfier, die Keywords sind) als auch der Definition von preprocessing-op-or-punc auftauchen?

Relevant ist DR 369.

Relevant für dieses Thema sind außerdem DR 985/2152, wo das Zusammenspiel von identifier und alternative token kracht. ""or"" ist nicht well-formed, obwohl or || gleichen soll.

Deine Erbsenzählerei ist daher unangebracht und peinlich.

Interessiert mich wenig, wie du weisst.

camper schrieb:

Die Anwendung dieser Regel ist ja wohl völlig daneben, da keine Funktionsdefinition existiert. Andernfalls wäre jedes Programm, dass constexpr-Funktionen bloss deklariert abder nicht definiert (und auch nicht verwendet) ill-formed.

Unsinn. Die Tatsache, dass die Funktion gar nicht erst definiert oder overriden werden kann, ist ausschlaggebend (und das ist auch offensichtlich das, worauf ich mich bezog, und nicht auf eine direkte Verletzung der ODR).

Schon klar, dass du das meinst. Der Textsinn des Zitates gibt es nur nicht her. Sollte dazu eine entsprechende ausdrückliche Äußerung des Standardkommitees existieren, lasse ich mich gerne überzeugen.

Arcoth schrieb:

Warum? Als Hüter des Standards weisst du am besten, dass solche Bemerkungen keinen normativen Charakter haben.

Nein, aber sie drücken Intention aus (was du als Hüter des Standards am besten weisst).

Ich weiss gar nichts. Ich kenne nur den Text.

Arcoth schrieb:

Die Autoren dieser Notiz waren höchstwahrscheinlich auch im Entwicklungsprozess von Klausel 2 involviert, was Aufschluss über die richtige Interpretation git. Dass alternative tokens containing alphabetic characters in solch expliziter Form erwähnt werden, macht wohl etwas deutlich.

Vielleicht. Vielleicht auch nicht. Vielleicht war sich der Author nur nicht völlig sicher. Vielleicht war der Bezug mal ein anderer. Fußnoten dieser Art fanden und finden sich im Standard einige. Jedenfalls hast du nicht verstanden, was was es heißt, dass Fußnoten, Beispiele, und Notizen keinen normativen Charakter haben: was auch immer sie aussagen, muss sich (soferen sie nicht einfach falsch sind), an anderer Stelle aus dem Text ableiten lassen. Diese Ableitung hast du nicht geliefert.
Anders gesagt: Die Stelle sagt, dass eine Regel existiert und nicht, was die Regel ist. Die Detektivarbeit endet hier nicht, sie beginnt überhaupt erst.

Und hier ist noch einmal mein strukturelles Argument, dass du einfach ignorierst:
Trotz der Tatsache, das ein eigener Abschnitt alternative representations shown in Table 5 for certain operators and punctuators existiert; werden die strittigen Token noch einmal in [lex.key] behandelt. Der Standard ist kein Roman; die Tatsache, wo sich eine bestimmte Norm befindet, hat ebenfalls Bedeutung. Wenn die alternativen Token so absolut überhaupt nichts mit Keywords zu tun haben, wieso sollte irgenjemand auf die Idee gekommen sein, das dort hinzuschreiben, wo doch schon ein Abschnitt für diese Token existiert?

Die Autoren dieses Anschittes haben sich höchstwahrscheinlich etwas bei Schreiben dieser Klausel gedacht, was Aufschluss über die richtige Interpretation git. Dass alternative representations for certain operators and punctuators in diesem Abschnitt auftauchen, macht wohl etwas deutlich.

Deine Argumentation wäre überzeugender, wenn du nicht nur Stellen heraussuchen würdest, die deine These (vermeintlich) stützen und den Rest unter den Tisch fallen lässt.

Arcoth schrieb:

Wo ist der Widerspruch? ....

Einen Widerspruch gab es nicht. Worauf ich mit dem Zitat hinaus wollte: Keywords werden aufgezählt; alternative tokens sind nicht inbegriffen. => Alternative tokens sind keine keywords, und der Unterschied kann beobachtet werden.

Wäre überzeugender, wenn der Text nicht so inkonsistent wäre.
Scheuen wir über den Tellerand, stellen wir fest, dass der Text für den Präprozessor von C90 übernommen wurde, ausser das in C (C90: 6.8.1; C99: 6.10.1) dort nur identifier steht.
Weil es Mode ist, mutmaße ich jetzt mal:
Ursprünglich existierten die strittigen alternative Token nicht, es existierten entsprechende Makros in <iso646.h>
Irgendjemand hielt es dann für eine gute Idee, die alternativen Token als festen Bestandteil des Sprachkerns einzuführen. Natürlich sollte sich Präprozessorcode nicht plötzlich anders verhalten, also muss klargestellt werden, dass die Äquivalenz von alternativem Token und entsprechendem Primärtoken [lex.digrah]/2 Vorrang vor der Ersetzung von identifier durch 0 haben soll. Irgenwann später stellt man fest, dass identifier ja fast überall im Standard nur die Token meint, die lexikalisch wie identifier aussehen und keine Keywords sind. Da aber auch Keywords im allg. Gegenstand dieser Ersetzung sind, verschlimmbessert man den Normtext, indem "remaining identifiers" durch "remaining identifiers and keywords", vergisst aber die Fußnote anzupassen.
(C11 macht es noch falscher, dort steht:

After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token.

wtf. jedenfalls ist klar, dass dieser Identifierbegriff nicht identisch mit dem im Rest des Standards ist)
In wirklichkeit haben Keywords hier nichts verloren, die existieren vor Übersetzungsphase 7 ja nicht als solche.
Dein Argument hängt also von der Konsistenz einer zu einem anderen Zeitpunkt enstandenen Bemerkung zu einem deplazierten Begriff an einer sehr weit vom Rest (Clause 2) entfernten Stelle ab.

Arcoth schrieb:

Deine Erbsenzählerei ist daher unangebracht und peinlich.

Interessiert mich wenig, wie du weisst.

Jetzt schon (ich habe kein Gedächtnis für so etwas). Sehr bedauerlich. Da du offenkundig nicht in der Lage bist, vernünftig einzuschätzen, ob eine Berichtigung zweckmäßig und angemessen ist, bitte ich dich, zukünftig weder auf meine Beiträge zu antworten noch derartiges Threadhijacking zu betreiben.

shade# schrieb:

Traurig das über solche Kindereien ausführlich diskutiert wird, aber andere Threads kaum antworten erhalten.

Nur dann, wenn man meint, jene anderen Threads hätten schon an sich einen höheren Wert. Dem Kindereien-Teil stimme ich allerdings zu.

Arcoth schrieb:

camper schrieb:

Die Anwendung dieser Regel ist ja wohl völlig daneben, da keine Funktionsdefinition existiert. Andernfalls wäre jedes Programm, dass constexpr-Funktionen bloss deklariert abder nicht definiert (und auch nicht verwendet) ill-formed.

Unsinn. Die Tatsache, dass die Funktion gar nicht erst definiert oder overriden werden kann, ist ausschlaggebend (und das ist auch offensichtlich das, worauf ich mich bezog, und nicht auf eine direkte Verletzung der ODR).

Schon klar, dass du das meinst. Der Textsinn des Zitates gibt es nur nicht her.

Wenn wir akribisch normativen Text interpretieren möchten, ist es völlig eindeutig, dass auch undefinierte Funktionen inbegriffen sind, woran der Anfang des Satzes nichts ändert.

Jedenfalls hast du nicht verstanden, was was es heißt, dass Fußnoten, Beispiele, und Notizen keinen normativen Charakter haben: was auch immer sie aussagen, muss sich (soferen sie nicht einfach falsch sind), an anderer Stelle aus dem Text ableiten lassen.

Doch, habe ich.

Trotz der Tatsache, das ein eigener Abschnitt alternative representations shown in Table 5 for certain operators and punctuators existiert; werden die strittigen Token noch einmal in [lex.key] behandelt. Der Standard ist kein Roman; die Tatsache, wo sich eine bestimmte Norm befindet, hat ebenfalls Bedeutung. Wenn die alternativen Token so absolut überhaupt nichts mit Keywords zu tun haben, wieso sollte irgenjemand auf die Idee gekommen sein, das dort hinzuschreiben, wo doch schon ein Abschnitt für diese Token existiert?

Footnote 16 nennt sie "lexical keywords". In früheren WPs waren in [lex.key] noch deutlich mehr, völlig deplatzierte Definitionen, die durch eine in N0904 beschriebene, editorische Aufteilung entfernt wurden. Niemand hat sie dort platziert, als der Abschnitt nur die eine Tabelle enthielt.

Irgendjemand hielt es dann für eine gute Idee, die alternativen Token als festen Bestandteil des Sprachkerns einzuführen. Natürlich sollte sich Präprozessorcode nicht plötzlich anders verhalten, also muss klargestellt werden, dass die Äquivalenz von alternativem Token und entsprechendem Primärtoken [lex.digrah]/2 Vorrang vor der Ersetzung von identifier durch 0 haben soll.

Soweit annehmbar klingend.

Irgenwann später stellt man fest, dass identifier ja fast überall im Standard nur die Token meint, die lexikalisch wie identifier aussehen und keine Keywords sind. Da aber auch Keywords im allg. Gegenstand dieser Ersetzung sind, verschlimmbessert man den Normtext, indem "remaining identifiers" durch "remaining identifiers and keywords", vergisst aber die Fußnote anzupassen.

Das ist falsch. Die Fußnote und die Addition von "and keywords" passierten gleichzeitig, und zwar im Übergang zum Oktober '97 WP.

Ich habe den Ursprung dieser Änderung lokalisiert (war gar nicht so einfach): Es ist N1095. In diesem Paper wurde auch der andere von mir zitierte Paragraph eingefügt: 485,493. Anscheinend handelt es sich um ein Kommentar von France; ich kann leider keine Erklärung dazu finden. Es ist IMO durch die vier in dem Paper gemachten Änderungen sehr suggestiv, dass alternative tokens in Konvertierungen zu tokens von preprocessing tokens als punctuators klassifiziert werden sollen - darum ja die Ergänzung von "and keywords" (weil wir von tokens sprechen).

In wirklichkeit haben Keywords hier nichts verloren, die existieren vor Übersetzungsphase 7 ja nicht als solche.

Im selben Satz wird erklärt, dass die preprocessor tokens in tokens verwandelt werden, welche keywords sein können. Ich mutmaßen jetzt mal: Die Konvertierung zu tokens sollte wohl vor der Ersetzung von keywords und identifiers durch 0 geschehen.

Da du offenkundig nicht in der Lage bist, vernünftig einzuschätzen, ob eine Berichtigung zweckmäßig und angemessen ist, bitte ich dich, zukünftig weder auf meine Beiträge zu antworten

Plonk mich, das kommt nämlich der Unsinnigkeit deiner Bitte gleich.

noch derartiges Threadhijacking zu betreiben.

Dieser Thread handelt sich um Codegolf. Hijacking ist hier ein Kavaliersdelikt.