Korrekte Gruppierung der ANSI/ISO C++ Schlüsselwörter
-
Hallo
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 grupppierenVielen 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
-
1. Welchen Sinn soll das ganze haben? Also welches Ziel verfolgst du damit?
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ätbb
-
Auch wenn sich mir nicht ganz erschliesst, wofür du das brauchst, hier mal ein Vorschlag. Ob die Schlüsselwörter offiziell wirklich in Gruppen unterteilt sind, weiss ich nicht. Ich hab Änderungen mit "<-" gekennzeichnet.
// 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 asmOkay, 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.
-
Hallo und Danke für eure Vorschläge. Also grundsätzlich brauche ich das einfach für mich selber. Ich mag es einfach eine Struktur aufzubauen, von etwas was mir etwas bedeutet. Für mich gibt es neben dem Programmcode schreiben eben noch mehr :). Der Sprachkern von C++ bildet sich nunmal aus Keywords und Operators. Und deswegen Strukturiere ich das für mich einfach ganz gerne. So wie ich bei Assembler auf Komplette Mnemonics Listen stehe.
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.
-
keywordy schrieb:
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.
-
Nexus schrieb:
[...]
In deiner Einteilung müßten, soweit ich es sehe,
static,classundusingzweimal vorkommen. Überthrowals Modifizierer könnte man streiten. Und in C++0x wären noch weiter Duplikationen vondefault,delete,class,sizeofundautovonnö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.
-
Nexus schrieb:
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.
-
audacia schrieb:
...anstatt sich über zweifelhafte Kategorisierungen derselben den Kopf zu zerbrechen.
Wiegesagt ich mache das für mich wie jemand der hald Ü Eier sammelt.
-
@ keywordy:
Okay, dann habe ich das etwas falsch verstanden. Ich kann deine Auffassung im Übrigen durchaus nachvollziehen, auch wenn ich sie persönlich nicht teile.@ 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...
-
keywordy schrieb:
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.
-
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
-
Um es vielleicht konkret und schnell auf den Punkt zu bringen: Ohne die definition der Sprache und die damit verbundenen möglichkeiten, gäbe es garkeine Programmiersprache. Alles im Leben muss definiert sein. Wenn die Sonne keine Strahlen abgeben würde, ist definiert was nicht existieren würde. Also:
class = Schlüsselwort = Sprachfeature = Sprachkern bestandteil = Konzept.
-> = operator = Sprachfeature = Sprachkern bestandteil = Möglichkeit / KonzeptabhängigkeitDie umsetzung der Konzepte = Programmieren. Hoffe nun kommt es hin.
-
audacia schrieb:
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.
-
volkard schrieb:
mist. welche syntax-regel ist verletzt worden?
In "mache" fehlt ein 'n'.