Verständnis "Ìnteger Constants"' - Verständnisfrage

Hallo und wiedermal vorab Danke für eure tolle Unterstützung. Ich habe gerade ein Verständnisproblem bei folgendem Sachverhalt:

Ich habe mich gerade über Konstanten in Arduino informieren wollen und kam auf diese Seite: https://www.arduino.cc/en/Reference/IntegerConstants

Kennen tue ich Konstante wie HIGH/LOW etc. Zudem aus C/C++ Konstante mit #define/const.

Nun ist meine Frage, wo bei dieser Arduino Definition das konstante bleibt. Es werden int float etc aufgeführt, aber mir ist nicht klar warum diese konstant sein sollten.

Danke an euch/dich! :)

aber mir ist nicht klar warum diese konstant sein sollten.

Weil sie da als Zahlen hingeschrieben worden sind, sind sie konstant. Feste Zahlen im Code sind konstant, auch wenn da kein const dran steht, oder #define genutzt wird.

int bla = 20;

bla ist eine Variable 20 eine Konstante

Tipp: Es gibt einen Unterschied zwischen Behälter und Inhalt.

Möglicherweise suchst Du nach:

const int LEDPin = 13;  // eine Konstante mit dem Wert 13
int wert = 25;          // eine Variable mit dem Anfangswert 25

Hm ok.

Behälter Int i, Inhlat konstanter Wert 20.
Also int i =20;

Der Wert der Variable ist 20=const. Die Variable per se ist jedoch veränderbar, also nicht const.

Soll die Variable einen konstanten Wert besitzen, brauche ich
const oder #define.

Das was der Artikel also darstellen will ist, dass Variablen konstante Werte übergeben werden und wie diese gewählt werden können?!?!

(Sorry, aber ich finde in meinem C/C++ Buch kein Kapitel, dass das so darstellt)

IO_HYBRIS_OI: Das was der Artikel also darstellen will ist, dass Variablen konstante Werte übergeben werden und wie diese gewählt werden können?!?! (Sorry, aber ich finde in meinem C/C++ Buch kein Kapitel, dass das so darstellt)

Öh ... und ich habe Probleme mit der Frage, was das Problem ist ... :-)

Vielleicht hilft das:

Wenn Du in einem Programm

int i=5;

schreibst, wird Speicher für ein int reserviert und als „i“ benannt. Was für einen Wert i hat, kann sich während des Programmablaufs ändern. Zu Beginn steht in i jedenfalls eine fünf.

Wenn Du hingegen

[b]const[/b] int i=5;

schreibst, weiß der Compiler, dass sich der Wert von i während des Programmablaufs nicht ändern darf. Wenn Du anderswo im Programm

i=6;

schreibst, bekommst Du beim Übersetzen (Compilieren) eine Fehlermeldung des Compilers. Dann kannst Du die Zeile korrigieren (weil Du eigentlich u meintest, das liegt auf der Tastatur neben dem i) oder löschen oder den Algorithmus anpassen.

Ich hoffe, das war verständlicher.

Gruß

Gregor

Zum Verständniss

"echte Konstanten" stehen nicht in Variablen sondern direkt im Quellcode

I=100 (a+b)/I /keine Konstante

const I=100 (a+b)/I /vieleicht Konstante, Compiler abhängig. Pascal bzw Delphi nimmt es als Variable aus dem Speicher

(a+b)/100 /echte Konstante, weil für die Zahl 100 keine Variable definiert ist und diese direkt im Quellcode steht

Hintergrund des ganzen

Zahlen im Quellcode benötigen 1-2 Takte weniger zur Verarbeitung. Man muss das gedanklich mal auf die Assemblercodes runter brechen. Bei Adresse muss ich - die Adresse laden - den Inhalt der Adresse holen - verarbeiten

Bei Zahl muss ich nur die Zahl holen und verarbeiten. Ich spare mir einen Speicherzugriff.

Der Compiler nimmt einem da viel ab, aber er entscheidet auch, wei es gemacht wird. (a+b)/99,5 ist zb keine Konstante beim Arduino (bzw Atmel-Prozessor), es wird intern eine Variable definiert und die Zahl im Speicher abgelegt, jedoch beim der 86er-Familie wird es als Constante eingebunden.

Warum?

die 86er haben seit dem 4er einen Mathecoprozessor und können Float direkt verarbeiten. Der arduino nicht, er muss float über eine Lib bearbeiten. Er kann also auch nur Integer bzw Byte aus dem Speicher direkt in Assembler verarbeiten. Alles andere muss er sich umschreiben und in mehrere Schritte aufteilen. Der Compiler weis das und macht die Dinge wie sie nötig sind. Vieles davon sehen wir nicht, wir benutzen daher den Begriff wie ihn der Compiler vorgibt. Deswegen schreibt man ja in Hochsprachen, weil einen Assembler eigentlich nicht interessiert.

Daher ist eine Konstante immer dann wenn man Const davor schreibt oder keinen Variablennamen angibt (Zahl direkt im Quellcode stehen hat). zB kann ein const float x = 87,4 keine Constante ergeben aus Sicht der CPU. Sie muss den Float aus dem Speicher holen und über ihre Bibliothek bearbeiten, da kein Mathecoprozessor on Board ist. Für uns als Programmierer ist es eine Konstante. Und der Compiler meckert, wenn wir x = 84,1 im Programm schreiben würden.

Ein bischen ist das ganze also Definitionsfrage und eine Frage der CPU und des Compilers und der Sprache. Es gibt (bzw gab) auch Sprachen ohne Konstanten. Und zwar dann wenn Daten und Programmcode strikt getrennt waren. Dort war es nicht erlaubt in den Programmcode die Zahl zu hinterlegen, es musste immer in den Datenbereich verwiesen werden und damit war es eine "Variable".

ich persönlich arbeite praktisch nie mit Konstanten, allenfalls mit define (also Ersetzungen). Aber das ist eher eine Angewohnheit. Wenns drum geht die letzte µsec rauszukitzeln ist const sogar sehr hilfreich.

(Sorry, aber ich finde in meinem C/C++ Buch kein Kapitel, dass das so darstellt)

Im Englischen nett sich die Konstante im Quellcode "Literal" Siehe z.B.: http://en.cppreference.com/w/cpp/language/integer_literal https://www.tutorialspoint.com/cprogramming/c_constants.htm

Zahlen im Quellcode benötigen 1-2 Takte weniger zur Verarbeitung

Das hängt stark von der jeweiligen Hardware ab, und ist ziemlich irrelevant.

Hier bei unseren Microcontrollern ist viel wichtiger, dass Variable Platz im sehr knappen RAM brauchen (zusätzlich zu ihrer Initialisierungskopie im Flash), während Quellcode-Konstante meist nur im Flash-Speicher zusammen mit dem Programm-Code sind.

Der Unterschied zwischen den Varianten

#define name wert
const typ name = wert;

ist, dass im zweiten Fall name einen Datentyp hat, während im #define Fall eine reine Text-Ersetzung vor dem Kompilieren erfolgt. Eine Fehlermeldung beim Kompilieren bezieht sich auf die ersetzte Zwischenversion, und ist daher üblicherweise schwerer zu verstehen.

Stimmt, den RAM-Speicher hatte ich nicht im Sinn hierbei, weil ich normalerweise immer davon ausgehe das auch das Programm im RAM liegt (PC-Programmierung).

Das ist natürlich ein gewaltiger Vorteil.

Wie ist das den mit den Speicherarten, sind die alle gleich schnell im Zugriff. Ich kenn das vom PC, wo das RAM immer schon deutlich schneller war als Eprom bzw Flash. So beim 386er hats ja angefangen das man das Bios isn RAM kopiert für schnellere Zugriffe.

Aber inzwischen sind die Speicherarten ja schneller geworden, meiner Meinung nach dürfte es nicht zu wait-states kommen. Aber ich hab mich bisher nicht so mit den Specs der CPU beschäftigt.

Aber ich hab mich bisher nicht so mit den Specs der CPU beschäftigt

viele 1 Takt Befehle, einige 2 Takt Befehle... Also keine Waits.

Ok, ich denke ich muss mir das Datenblatt nun doch mal durcharbeiten.

Die CPU ist komplexer als ich erwartet habe bei einem 8-bitter.