Wie viele Schlüsselwörter könnt ihr in aneinanderreihen

[Columbo]

if(true); else do extern constexpr const volatile unsigned long long int n(); while(false);

[sebi707]

camper schrieb:

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.

[TyRoXx]

struct test
{
  test & operator*(test &)
  {
    return *this**this**this**this**this**this**this**this**this**this**this**this;
  }
};

Zählt das auch?

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

[Th69]

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

[camper]

Th69 schrieb:

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.

[volkard]

Bitte ein ausführbares Programm also mit der main()
und als Wettbewerb die meisten verschiedenen Schlüsselwörter in Folge
und

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

[Columbo]

@camper: Teste deinen Code mal. Eine constexpr Funktion darf nicht als virtual definiert werden ([dcl.constexpr]/(3.1)). Im Übrigen sind xor usw. keine keywords.

[hustbaer]

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

[klassenmethode]

#define int(int) int
#define short main
#define long x
#define double y
//start
int(int(int(int(int(int(int(int(int(int(int)))))))))) 
short(int(int(int(int(int(int(int(int(int(int(int))))))))))long,
     int(int(int(int(int(int(int(int(int(int(int))))))))))double){};
//end

[camper]

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;
};

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]

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.

[camper]

volkard schrieb:

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();

[hustbaer]

Und #define sollte vermutlich ausgeschlossen werden. Bzw. am besten gleich der ganze PP.
Sonst schreibe ich

//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
)

[Columbo]

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.

Arcoth schrieb:

Im Übrigen sind xor usw. keine keywords.

Zitat?

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

[camper]

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

[Columbo]

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.

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?

[Columbo]

Und hier sind 10 unterschiedliche von mir:

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

[camper]

Arcoth schrieb:

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.

[Columbo]

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

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.

[shade#]

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