Ich mache mir gerade eine Liste mit Gruppierten ANSI/ISO C++ Schlüsselwörter. Für mich wichtig, für euch wahrscheinlich nicht relevant :). Aber ich bitte all diejenige die wirklich wissen, wie man es gruppiert und wie man die Gruppen nennt, meine untenstehende Liste zu bearbeiten. Bitte:

a) Falls notwendig, die vorhandenen Gruppen richtig bezeichnen / erweitern
b) Falls Schlüsselwörter in einer Gruppe fehlen oder falsch sind, bitte verschieben
c) Schlüsselwörter welche in keiner Gruppe sind (am Ende) bitte korrekt grupppieren

Vielen Dank!

//TYPEN
char
wchar_t
short
int
long
float
double
bool
void
unsigned
signed

//BEDINGUNGEN-ANWEISUNGEN-SCHLEIFEN
if
else
switch
case
default
do
while
for
continue
break

//VERBUNDDATENTYPEN
struct
enum
union

//KLASSE
class
public
private
protected
friend
virtual
this

//TYPUMWANDLUNG
const_cast
reinterpret_cast
static_cast
dynamic_cast

//WAHRHEITSTYPEN
true
false

//AUSNAHMEBEHANDLUNG
throw
try
catch

//SPEICHERKLASSEN
static
extern
register
auto
mutable

//UNKLAR WOHIN / GRUPPENBEZEICHNUNG
new
delete
typedef
typeid
typename
using
namespace
inline
template
export
asm
explicit
goto
operator
return
sizeof
const
volatile

Ich versuch mich mal, auch wenn ich es eigtl unsinnig find ^^

//TYPEN 
char 
wchar_t 
short 
int 
long 
float 
double 
bool 
void 
unsigned 
signed 
typedef //kA, wohin sonst...

//BEDINGUNGEN-ANWEISUNGEN-SCHLEIFEN 
if 
else 
switch 
case 
default 
do 
while 
for 
continue 
break 

//VERBUNDDATENTYPEN 
enum 
union 
struct 
class 
public 
private 
protected 
friend 
virtual 
this 
explicit 
operator 

//TYPUMWANDLUNG 
const_cast 
reinterpret_cast 
static_cast 
dynamic_cast 

//WAHRHEITSTYPEN 
true 
false 

//AUSNAHMEBEHANDLUNG 
throw 
try 
catch 

//SPEICHERKLASSEN 
static 
extern 
register 
auto 
mutable 
volatile
const //ich packs einfach mal mit hierhin, obwohl ich damit (u.a.) nicht ganz glücklich bin ^^

//SPEICERVERWALTUNG
new 
delete 

//templates
template 
typename 
export 

//namespaces
using 
namespace 

//fkt
inline 
return 

//bleibt noch:
typeid //evtl ne extra kat. "RTTI"
sizeof //vll bei speicherverwaltungszeugs iwie
asm //adapter zu maschinensprachen
goto //maschinensprachen-kompatibilität

bb

// FUNDAMENTALE TYPEN <--
char
wchar_t
short
int
long
float
double
bool
void
unsigned
signed

// SPEICHERKLASSEN-QUALIFIZIERER <-
static
extern
register
auto

// CV-QUALIFIZIERER     <-
const
volatile

// KONTROLLSTRUKTUREN   <-
if
else
switch
case
default
do
while
for
continue
break
goto             // <-
return           // <-

// ZUSAMMENGESETZTE TYPEN  <- class und struct zu trennen finde ich nicht gut
enum             // <-
union            // <-
struct           // <-
class
public
private
protected
friend
virtual
this
mutable           // <- keine Speicherklasse
explicit          // <- kommt nur im Zusammenhang mit Konstruktoren vor

// TYPUMWANDLUNG
const_cast
reinterpret_cast
static_cast
dynamic_cast

// BOOL-LITERALE     <-
true
false

// AUSNAHMEBEHANDLUNG
throw
try
catch

// FUNKTIONEN        <-
inline
operator

// COMPILEZEIT-POLYMORPHIE <- zugegebenermassen nicht der beste Name...
typedef
typename
template
export
sizeof

// DYNAMISCHE SPEICHERVERWALTUNG <-
new
delete

// NAMENSRÄUME <-
using
namespace

// RESTLICHE SCHLÜSSELWÖRTER <-
typeid
asm

Okay, gegen den Schluss sind es etwas viele kleine Gruppen, aber mir fällt auch keine sinnvolle andere Klassifizierung ein. Eventuell könnte man die Gruppen Namensräume und Compilezeit-Polymorphie noch zusammenfassen, aber ich hab jetzt keinen passenden Überbegriff gefunden...

Mich würde trotzdem mal interessieren, wofür du das brauchst.

In der Realität meines Lebens sieht das so aus, dass ich grifffeste Bestandteile bilde und brauche. Soll heissen: Eine Programmiersprache wirdprimär durch Schlüsselwörter und Operatoren gebildet. Sie machen also die eigentliche Programmiersprache aus. Beim Assembler ist es der Befehlssatz, was den Prozessor ausmacht. Der festgelegte Befehlssatz (also die Mnemonics) beschreiben, wie der Prozessor nun also zu arbeiten hat und nicht anderst. Und dann kommen wir an die unterste Ebene an, die Elektronik. Anhand der Maschinenbefehle werden Elektronische Wellen ereugt die dann genau das machen was man als Mensch erwartet. Das war ein kleiner einblick in meine Entwicklerwelt :). Don't be freaked out! It's just me.

Eine Programmiersprache wirdprimär durch Schlüsselwörter und Operatoren gebildet. Sie machen also die eigentliche Programmiersprache aus.

Das würde ich nicht unbedingt sagen. Sie machen die Syntax aus. Aber was vielleicht bei Assembler nicht so entscheidend ist, sind bei C++ die Konzepte und Programmierparadigmen, welche die Sprache bietet. Darauf kommt es nachher tatsächlich an, das ist auch primär das, was C++ von anderen Sprachen abgrenzt.

Genauso bedeutet es nichts, wenn man von sich sagen kann, alle Schlüsselwörter zu kennen. Es kann gut sein, dass man dann noch weit davon entfernt ist, die Sprache zu verstehen.

[...]

In deiner Einteilung müßten, soweit ich es sehe, static , class und using zweimal vorkommen. Über throw als Modifizierer könnte man streiten. Und in C++0x wären noch weiter Duplikationen von default , delete , class , sizeof und auto vonnöten

Anders gesagt (an den Threadersteller): es ist vielleicht besser, die Zeit mit dem Erlernen der Features hinter den Schlüsselwörtern besser zu verbringen, anstatt sich über zweifelhafte Kategorisierungen derselben den Kopf zu zerbrechen.

Das würde ich nicht unbedingt sagen. Sie machen die Syntax aus. Aber was vielleicht bei Assembler nicht so entscheidend ist, sind bei C++ die Konzepte und Programmierparadigmen, welche die Sprache bietet. Darauf kommt es nachher tatsächlich an, das ist auch primär das, was C++ von anderen Sprachen abgrenzt.

Ich habe mir schon gedacht das ein Wiederspruch kommt :). Scheinbar bin ich der einzigste C++ Programmierer der diese Ansicht hat. Es ist richtig das mein genanntes den Syntax bildet, das meinte ich damit ja auch. Und der Syntax bildet ja im Endeffekt die Programmiersprache. Wenn ich von der Programmiersprache rede, ist die STL aussen vor gelassen.

Die STL ist nicht die Programmiersprache, sondern eine Bibliothek, welche als bestandteil angesehen werden kann. Aber die Sprache machen nunmal Wörter und Operatoren aus. Wie eine Menschliche Sprache dies tut. Die damit verbundene Technische Gramatik macht dann das eigentliche Programmieren aus. So wie der Code mit Logik, Assoziationen, Struktur und Aufbau zusammenhängt, spricht man vom Programmieren (meiner Meinung nach). Ohne die Schlüsselwörter und Operatoren gebe es keine Regelung für das Maschinencode Muster, ergo kein C++. Selbst die STL wurde in ISO C++ und Assembler geschrieben.

Nexus schrieb:

Genauso bedeutet es nichts, wenn man von sich sagen kann, alle Schlüsselwörter zu kennen. Es kann gut sein, dass man dann noch weit davon entfernt ist, die Sprache zu verstehen.

Da hast du absolut recht Nexus und da stimme ich dir auch zu. Das war ja auch nicht meine Aussage diesbezüglich :). Die Reihenfolge setze ich da sowieso umgekehrt. Sprache lernen, Schlüsselwörter und Operatoren Strukturieren können. Es ist schon klar das man erst dann programmieren kann wenn man die Philosophie des Programmieren versteht. Natürlich bringt es niemandem etwas zu wissen das class ein Sprachfeature ist und man damit eine Klasse bilden kann, sollange man nicht verstehen kann wozu Grundlegende sachen wie Variablen dienen, was mit ihnen passiert, wie Polimorphie zu nutzen ist, was mit den Methoden geschieht, wozu der Scope ist, etc.

Es konnte mich in meiner Schlüsselwörter/Operatoren = Sprachkernbildung Theorie leider noch nie jemand (ausser meiner Freundin), verstehen. Was aber nicht schlimm ist, um Gottes Willen.

...anstatt sich über zweifelhafte Kategorisierungen derselben den Kopf zu zerbrechen.

Wiegesagt ich mache das für mich wie jemand der hald Ü Eier sammelt.

@ audacia:
Ja, ganz konsequent ist es nicht. War ja auch nur ein möglicher Vorschlag, den Sinn davon habe ich ja bereits selber in Frage gestellt...

Und der Syntax bildet ja im Endeffekt die Programmiersprache.

http://de.wikipedia.org/wiki/Syntax

Die Programmiersprache hebt grüne Regeln mit Badesalz, obwohl manche Blutstiftungen dem Gras fleißig die Felgen spalten.

edit: das zuvor fehlende 'n' in "manche" eingefügt.

Die Programmiersprache hebt grüne Regeln mit Badesalz, obwohl mache Blutstiftungen dem Gras fleißig die Felgen spalten.

Sehr schönes Beispiel. Leider syntaktisch fehlerhaft

class = Schlüsselwort = Sprachfeature = Sprachkern bestandteil = Konzept.
-> = operator = Sprachfeature = Sprachkern bestandteil = Möglichkeit / Konzeptabhängigkeit

Die umsetzung der Konzepte = Programmieren. Hoffe nun kommt es hin.

volkard schrieb:

Die Programmiersprache hebt grüne Regeln mit Badesalz, obwohl mache Blutstiftungen dem Gras fleißig die Felgen spalten.

Sehr schönes Beispiel. Leider syntaktisch fehlerhaft

mist. welche syntax-regel ist verletzt worden?

http://de.wikipedia.org/wiki/Syntax schrieb:

Unter der Syntax einer formalen Sprache (formale Syntax) – wie etwa Programmiersprachen in der Informatik oder Kalküle in der Logik – versteht man ein System von Regeln, nach denen erlaubte Konstruktionen bzw. wohlgeformte Ausdrücke aus einem grundlegenden Zeichenvorrat (dem "Alphabet") gebildet werden[5] – wobei von der inhaltlichen Bedeutung der Zeichen abgesehen wird bzw. werden kann.

Eine formale Syntax kann graphisch mittels Syntaxgraphen beschrieben werden.

So meinte ich das eigentlich ungefähr auch.

mist. welche syntax-regel ist verletzt worden?

In "mache" fehlt ein 'n'.