Diskussion:C++-Programmierung/ Einführung in C++/ Variablen, Konstanten und ihre Datentypen

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
Aus Wikibooks

Kritikpunkte 1: Fehler[Bearbeiten]

  • (const) "Es gehört immer zu dem, was rechts davon steht, es sei denn, rechts steht nichts mehr, dann gehört es zu dem Teil auf der linken Seite." Es ist genau andersrum. Bei komplexeren Datentypen wird das relevant, etwa char const * (Zeiger auf konstantes char) im Vergleich zu const char * (ebenfalls: Zeiger auf konstantes char) oder char * const (konstanter Zeige auf nicht-konstantes char).
Sorry, das war ein ganz bösartiger Dreher von mir, hab's berichtigt. --Prog 17:20, 24. Sep. 2007 (CEST)[Beantworten]
:-) --RokerHRO 17:43, 24. Sep. 2007 (CEST)[Beantworten]
  • die Empfehlung zur Wahl des richtigen Datentyps ("so klein wie möglich, so groß wie nötig")ist ebenfalls unklug. Es gibt Architekturen, wo die CPU ein (16-bit-)short wesentlich langsamer handhaben kann, als ein (32-bit)int. Die Empfehlung sollte daher eher so lauten: "Wähle ein int, wenn dieser Typ alle Zahlen des Wertebereichs aufnehmen kann, bei vorzeichenlosen Zahlen unsigned. Reicht dieser Wertebereich nicht aus und ist long größer, nimm long (bzw. unsigned long). short und unsigned short sollte nur Verwendung finden, wenn Speicherplatz knapp ist, etwa bei Verwendung großer Arrays, oder wenn low-leve-Datenstrukturen festgelegter Größe benutzt werden müssen."
Einverstanden und übernommen. --Prog 17:20, 24. Sep. 2007 (CEST)[Beantworten]
:-) --RokerHRO 17:43, 24. Sep. 2007 (CEST)[Beantworten]
  • Es ist nicht festgelegt, dass sizeof(bool) == 1 ist. Es kann auch größer sein. Und auf Prozessor-Architekturen, die nur mühsam auf Einzelbytes zugreifen können, ist das auch sehr sinnvoll, ein bool so groß wie ein int zu definieren.
Habs geändert so dass das deutlich wird --Prog 17:20, 24. Sep. 2007 (CEST)[Beantworten]
Ich würde gar keine Annahmen darüber treffen, wie groß ein bool ist, da der Standard darüber keine Anforderungen stellt. 1 und sizeof(int) sind durchaus die sinnvollsten Festlegungen, aber ... vorgeschrieben sind diese Größen nicht. --RokerHRO 17:43, 24. Sep. 2007 (CEST)[Beantworten]


  • Was ist Ansi-C++? Ich kenne nur ISO-C++. Möglich, dass das ANSI den Standard übernommen hat. Federführend ist aber die ISO, was C++ angeht.
Richtigerweise hätte hier ISO stehen müssen, thx --Prog 17:20, 24. Sep. 2007 (CEST)[Beantworten]
--RokerHRO 10:27, 24. Sep. 2007 (CEST)[Beantworten]
  • Definition vs. Deklaration: In Abschnitt 2 ("Variablen") steht: "... Dies ist insofern wichtig, als dass eine Definition immer nur einmal geschrieben werden darf, während eine Deklaration beliebig oft vorgenommen werden kann. ...". Ist das so richtig oder sollten "Definition" und "Deklaration" hier gerade vertauscht stehen? --HerrPi 12:17, 3. Jan. 2013 (CET)[Beantworten]
Ist richtig so. extern const float PI = 3.14159; ist eine Definition. Es wird PI als Name eingeführt (deklariert) und gleichzeitig Speicher angelegt, was nur einmal passieren darf. Das macht es zur Definition. Die reine Deklaration extern const float PI; dagegen kann dann beliebig häufig im Quellcode auftauchen. --92.196.53.42 12:50, 3. Jan. 2013 (CET)[Beantworten]

Kritikpunkte 2: Sonstiges[Bearbeiten]

  • Die Erläuterungen über die interne Darstellung von ganzen und Gleitkommazahlen ist wichtig genug, dass sie in dieses Buch gehört, aber ich denke, sie macht dieses Kapitel sehr lang und schwer verständlich. Ich wäre daher dafür, diese Abhandlung in ein separates Kapitel oder in den Anhang auszulagern.
Ich würde mich freuen wenn du dazu ein Kapitel schreiben könntest, schließlich hast du in deinem Turorial ja eigentlich schon alles zu stehen. ;-) --Prog 17:20, 24. Sep. 2007 (CEST)[Beantworten]
Du kannst es gerne incl. der Grafiken übernehmen. --RokerHRO 17:43, 24. Sep. 2007 (CEST)[Beantworten]
Werd mal sehen ob ich demnächst dazu komme --Prog 21:26, 24. Sep. 2007 (CEST)[Beantworten]
  • Es gibt sehr wohl auch die Datentypen signed short, signed int und signed long nur sind die - im Gegensatz zu signed char, wie ja auch im Text sehr richtig steht :-) - mit den jeweiligen Datentypen ohne "signed" identisch, daher ist das Schlüsselwort "signed" dort redundant und entfällt üblicherweise. Es sollte trotzdem erwähnt werden, dass es das gibt. (Und manchmal dient es durchaus der Lesbarkeit, wenn man durch Einfügen des redundanten "signed" eben deutlich machen will, dass man es mit vorzeichenbehafteten Zehlen zu tun hat.)
Ich denke jetzt ist es etwas besser --Prog 17:20, 24. Sep. 2007 (CEST)[Beantworten]
Etwas. :-) --RokerHRO 17:43, 24. Sep. 2007 (CEST)[Beantworten]
--RokerHRO 10:27, 24. Sep. 2007 (CEST)[Beantworten]

Code-Formatierung[Bearbeiten]

Vielleicht ein wenig off-topic hier, aber hier ist es mir grad aufgefallen: Wieso muss der Quellcode physisch formatiert werden? Kann Mediawiki keine logische Textformatierung für Quellcode? Ich finde die Standard-Formatierung von <source lang="cpp"> z.B. grässlich, aber dort kann ich sie IMHO über eigene .css-Dateien anpassen. Wenn die Quellcodebeispiele hier aber physisch formatiert werden, geht das leider nicht mehr. --RokerHRO 17:43, 24. Sep. 2007 (CEST)[Beantworten]

Die Syntaxhervorhebeung ist noch neu und bisher auch nur für Codeblöcke verfügbar (also nicht im normalen Text, auch wenn daran gearbeitet wird), leider ist auch die Darstellung zum Teil völlig fehlerhaft:
#define irgendwas \
    sollte auch farbig sein

// Das ist ein Kommentar
#define test          // Kommentar

if while throw true
und das sind nur die Sachen die mir auf Anhieb einfallen, da gibt's leider noch viel mehr... "physisch formatiert" kannst du also vorerst leider als Wunschtraum verbuchen. Auf der Seite von GeSHI[1] kannst du dir denn Quellcode ja mal spasseshalber heruntergeladen, er ist halt so gehalten das er auf möglichst einfache weise für möglichst viele sprachen funktioniert. Darunter leidet dann natürlich die Qualität der einzelnen Sprachen. --Prog 21:26, 24. Sep. 2007 (CEST)[Beantworten]
Ja, das source-Skript ist sicher nicht perfekt. Aber es erzeugt logisch formatierten HTML-Code:
<pre class="source-cpp"> <span class="co2">#define irgendwas \</span> ...
Und den kann ich dann - sofern die CSS-Klassen vom Skript richtig gesetzt werden (was, wie dein Beispiel zeigt, momentan noch nicht 100% klappt) - über benutzerdefinierte .css-Definitionen eigene Formate zuweisen. Verstehst du, was ich meine? --RokerHRO 00:14, 25. Sep. 2007 (CEST)[Beantworten]

Codeformatierung Teil 2[Bearbeiten]

Wieso schreibst du immer <code><span style="..."> ... </span><code> statt <code style="..."> ... </code>? Deine Formatierung bläht den Wikicode sehr auf und macht ihn extrem schwer lesbar. :-( --RokerHRO 13:19, 3. Jan. 2008 (CET)[Beantworten]

Compiletime-Konstanten und Laufzeit-Konstanten[Bearbeiten]

Ich denke, der Unterschied zwischen diesen beiden sollte auf jeden Fall erwähnt werden, da es schnell zu Überraschungen kommen kann, etwa in folgendem Beispiel:

const double   FACTOR = 0.75;
const unsigned WIDTH  = 256*256;
const unsigned HEIGHT = unsigned(FACTOR * WIDTH);

unsigned char aw[ WIDTH ];  // okay
unsigned char ah[ HEIGHT ]; // Compiler-Error: "error: array bound is not an integer constant"
unsigned char aj[ unsigned(0.75 * WIDTH) ]; // okay

--RokerHRO 12:42, 10. Okt. 2007 (CEST)[Beantworten]

In diesem Beispiel ist der Compiler immer in der Lage den Wert von HEIGHT zur Compilezeit zu ermitteln. g++ übersetzt dies auch anstandslos. Hast du dich möglicherweise bei dem Beispiel vertan?
Meine 2. Frage ist: Gibt es im C++-Standard eine Vorschrift, was Laufzeit- und was Compilezeit-Konstanten sind? Ich wollte das hier jetzt endlich mal in das Kapitel einarbeiten, aber ich möchte natürlich nichts falsches schreiben. Danke im voraus --Prog 17:22, 27. Sep. 2008 (CEST)[Beantworten]
1.) Dass dein gcc das ohne Fehler übersetzt, bezweifle ich. Ich habe den Code eben nochmal rauskopiert und versucht, mit g++ -Wall -c example.cc zu übersetzen. Auf g++ 4.1.2 gibt es jedenfalls oben genannten Fehler. Welche Version benutzt du? Hast du den Beispielcode auch exakt so übernommen?
2.) Siehe Kapitel 5.19 Constant expressions im ISO-Standard. Kurzum: Als Arraygrenze, Case-Ausdruck, Bitfield-Längenangabe, Enumerator-Initialisierer, Initialisierer von statischen Membern und als Aufzählungs- oder Integer-Template-Argument sind nur "constant expressions" erlaubt. Diese dürfen nur aus Literalen, Enumeratoren, const-Variablen von Ganzzahl- oder Aufzählungs-Typen und sizeof()-Ausdrücken bestehen. Gleitkomma-Literale dürfen nur benutzt werden, wenn sie in einen Ganzzahl- oder Aufzählungstypen umgewandelt werden (wie dies bei aj der Fall ist). Die Initialisierung von HEIGHT benutzt jedoch eine double-Variable, somit ist HEIGHT kein "constant expression".
--RokerHRO 20:46, 1. Okt. 2008 (CEST)[Beantworten]
Danke für deine Antwort. Ich hatte den Code in den Schleifenrumpf von main() übernommen, dort wird er anstandslos übersetzt. Nachdem ich ihn nun in den globalen Namensraum geschrieben habe, bekomme ich die von dir beschriebene Fehlermeldung. Ich muss infolge dessen leider noch mal dumm nachfragen: Ist es korrekt wenn mein g++ (4.3.1) den Code im Funktionsrumpf übersetzt?
Jain. Mit -std=c++98 -pedantic übersetzt, dürfte es nicht funktionieren. Grund: Es gibt in ISO C++ keine "variable length arrays". Dies ist eine GNU-Erweiterung für C90 und C++ (In C99 sind sie erlaubt). Mit obigen Optionen kommt dann nämlich auch erwartungsgemäß: error: ISO C++ forbids variable-size array 'ah'.
Also: Es ist okay, wenn der gcc das mit (standardmäßig aktivierten) GNU-Erweiterungen frisst. Er versteht den Code, aber er weiß auch, dass er in ISO C++ (leider) nicht erlaubt ist. --RokerHRO 11:16, 2. Okt. 2008 (CEST)[Beantworten]
Auf deine Kritik, die du an einigen stellen zu meinem Schreibstil hinterlassen hast, möchte ich an dieser Stelle auch kurz Antworten. Ich werde versuchen die Kapitel entrechend deinen Vorschlägen abzuändern und ich habe mir auch vorgenommen, den Seite demnächst aussagekräftigere Namen zu geben. Da ich jedoch nicht sehr Regelmäßig an dem Buch arbeite und zwischen meinen (dann meist gehäuften Arbeiten) oft längere Zeitspannen liegen kann es eine Weile dauern bis alles angepasst wurde. Ich verspreche jedoch die Diskussionsseiten nicht aus dem Blick zu verlieren.
Ich weiß, solche Überarbeitungen dauern länger als Tippfehler- und Kommakorrekturen. Aber: Es lohnt sich! Nur Mut! --RokerHRO 11:16, 2. Okt. 2008 (CEST)[Beantworten]
Besonders hilfreich finde ich deine Ausführungen über Blockanweisungen, das wird den Schreibaufwand vermindern und die Übersicht erhöhen, da es die Struktur des Buches verbessert. Freundliche Grüße --Prog 00:13, 2. Okt. 2008 (CEST)[Beantworten]

Variablen, Objekte und Typen[Bearbeiten]

Auch hier werden die Begriffe "Variable" und "Objekt" und "Typ" munter miteinander vermischt. Das ist sehr schade, verwirrt den Leser hier vielleicht noch nicht, aber es bereitet ihm mit Sicherheit später arge Probleme, wenn es nötig wird, diese Begriffe zu unterscheiden. Siehe (fürs erste) Kapitel 1.8, 3 und 3.9 im ISO-Standard. Da ist das alles sehr detailiert (und auch verständlich, wenn auch recht trocken) beschrieben. --RokerHRO 22:07, 1. Okt. 2008 (CEST)[Beantworten]

falsche Dokumentation von string-Konstanten?[Bearbeiten]

Diese Zeile irritiert mich:

 "Ich bin ein Text"  // char*

Meines Wissens ist das nicht vom Typ `char *', sondern `const char *'. C++ kann da sehr pingelig sein... Oder irre ich mich? -- Lemzwerg 07:52, 3. Nov. 2010 (CET)[Beantworten]

Richtig, Danke. :) --Prog 16:33, 3. Nov. 2010 (CET)[Beantworten]
Zeichenkettenliterale sind nicht vom Typ const char*, sondern char[n], wobei n die Anzahl der Zeichen – incl. abschließendem Nullbyte – ist. Ein typeid("Foo").name() gibt dann auch ensprechendes aus, z.B. A5_c beim GCC (das man mit c++filt -t A5_c dekodieren kann und man bekommt *trommelwirbel* char [5]). Ach ja: sizeof("xy") ist auch 3 und nicht sizeof(char*). --RokerHRO 21:49, 7. Feb. 2012 (CET)[Beantworten]

Zeichen und Zeichenketten – einfache und doppelte Anführungszeichen[Bearbeiten]

In verschiedenen Code-Fenstern sind mal einzelne Zeichen in 'einfachen Anführungszeichen' und mal Zeichenketten in "doppelten Anführungszeichen" zu sehen. Aber im Text wird darauf gar nicht eingegangen. Ich meine, das muss spätestens in diesem Kapitel an geeigneter Stelle erklärt werden oder vielleicht auch schon vorher im Kapitel „Einfache Ein- und Ausgabe“. Also wann sind einfache und wann sind doppelte Anführungszeichen zu benutzen bei Verwendung von Literalen, Variableninitialisierung und -zuweisung, Konstanten etc. und was passiert bei fehlerhafter Verwendung. Leider habe ich als Anfänger nicht genug Kenntnisse über C++, um das selbst zu ergänzen. --Pohli 03:28, 5. Aug. 2018 (CEST)[Beantworten]

Ich habe gerade gesehen, dass es im nächsten Abschnitt ein Kapitel namens „Zeichenketten“ gibt aber das ist von hier aus gesehen noch weit weg und außerdem werden dort anscheinend (habe jetzt nicht alles gelesen) nicht die Fragen geklärt, die ich hier gestellt habe. Also meine Anmerkungen von oben haben weiterhin Bestand. --Pohli 04:12, 5. Aug. 2018 (CEST)[Beantworten]

Es gibt vorher schon C++-Programmierung/_Einführung_in_C++/_Variablen,_Konstanten_und_ihre_Datentypen#Literale_und_ihre_Datentypen. Gleich das 1. Beispiel sollte könnte man um eine Zeichenkette ergänzen und vielleicht im Kommentar die Bedeutung von ' und " klären. Nachtrag: Sehe ich jetzt erst. Das hier ist ja die Kommentarseite der Seite, auf die ich verwiesen habe. Eigentlich gehören die Literalschreibweisen jedes Typs an den Anfang. --92.202.163.244 09:37, 5. Aug. 2018 (CEST)[Beantworten]
Ich habe gerade etwas Grundlegendes im Kapitel Einfache Ein- und Ausgabe ergänzt. Verbesserungen und Ergänzungen erwünscht. Vielleicht könnte man trotzdem noch mehr in diesem Kapitel (Variablen, Konstanten und ihre Datentypen) dazu schreiben. --Pohli 22:03, 7. Aug. 2018 (CEST)[Beantworten]