Korrekte Gruppierung der ANSI/ISO C++ Schlüsselwörter

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.

Nexus

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.

audacia

Nexus schrieb:

[...]

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.

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.

Nexus

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

volkard

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.

audacia

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ängigkeit

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

volkard

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?

@volkard:

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.

audacia

volkard schrieb:

mist. welche syntax-regel ist verletzt worden?

In "mache" fehlt ein 'n'.