in einem anderen Beitrag wurde mir dazu geraten, mehr in Unterprogrammen zu programmieren und denken. Das wollte ich mal umsetzen, bekam dann aber Probleme mit den Variablen.
Eine Funktion schreibe ich ja wie folgt:
void xyz() {
INHALT
}
Mein Code der zuvor in der void loop() lief, hat dann aber mit der neuen Ordnung nicht mehr funktioniert.
"xxx was not declared in this scope".
Ich glaube auch davon gelesen zu haben, dass es Variablen gibt, die nur für manche Funktionen sichtbar sind.
Macht es einen Unterschied, in welcher Reihenfolge der Programmcode seht?
Sicher wurde dir nicht geraten, Unterprogramme zu schreiben.
Die gibt es in C++ nicht. Die heißen Funktionen.
Und auch werden Sketche, auch Teile davon in Code-Tags gepostet.
Hanswurst123:
Ich glaube auch davon gelesen zu haben, dass es Variablen gibt, die nur für manche Funktionen sichtbar sind.
Es gibt globale und lokale Variablen, deren Sichtbarkeit global oder lokal ist:
int globale_Variable = 5; // überall sichtbar
void setup(){}
void loop(){
int lokale_loop_Variable = 7; // nur in loop sichtbar
}
void xyz(){
int lokale_xyz_Variable = 9; // nur in xyz sichtbar
}
Hanswurst123:
Macht es einen Unterschied, in welcher Reihenfolge der Programmcode steht?
Nein. Funktionen können sogar in unterschiedlichen Dateien stehen, wenn man das dem Kompiler mitteilt.
Und ganz nebenbei:
Das void ist der Rückgabetyp der entsprechenden Funktion.
void: gibt keine Rückgabe
int: Rückgabe vom Typ int
byte: Rückgabe vom Typ Byte
void setup(void) sagt nur: keine Rückgabe von der Funktion, keine Übergabe in die Funktion
Hanswurst123:
"xxx was not declared in this scope".
Ich glaube auch davon gelesen zu haben, dass es Variablen gibt, die nur für manche Funktionen sichtbar sind.
Variablen existieren immer nur innerhalb „ihres“ Blocks, der von { und } begrenzt ist. Außerhalb dieser Klammern ist eine Variable nur sichtbar, wenn sie global ist oder sich innerhalb eines übergeordneten Blocks befindet.
{
byte a;
{
byte b;
// Hier sind a und b sichtbar/existent
} //<-- hier wird b vernichtet
} //<-- hier wird auch a vernichtet
Eigentlich gibt es ja in C und C++ keine globalen Variablen, welche überall sichtbar sind.
Variablen sind immer nur in ihrer Übersetzungseinheit sichtbar.
Wenn eine Variablen Definition in einer anderen Übersetzungseinheit sichtbar/nutzbar sein soll, muss man sie in dieser als "extern" deklarieren.
Dann erst greifen die (geschachtelten) Blockklammern, welche jeweils ihren Geltungsbereich aufziehen.
Namspaces erlauben dann noch Zugriffe in Blockklammern hinein.
combie:
Eigentlich gibt es ja in C und C++ keine globalen Variablen, welche überall sichtbar sind.
Variablen sind immer nur in ihrer Übersetzungseinheit sichtbar.
Solange eine 'global' definierte Variable nicht als 'static' gekennzeichnet ist, ist sie für den Linker sichtbar - und damit auch über die Übersetzungseinheit hinaus global. Man kann den gleichen Namen nicht in einer anderen Übersetzungseinheit als neue Variable definieren (auser man nutzt Namespaces). Da würde der Linker meckern. Alles, was der Linker kennt, ist Übersetzungseinheiten übergreifend global.
Über das Schlüsselwort 'extern' kann man sie in einer anderen Übersetzungseinheit bekannt machen. 'Automatisch' sichtbar sind sie dort allerdings in der Tat nicht.
Ja, ok. Ich wollte auch nur darauf hinweisen, dass alles, was der Linker sieht, über die Übersetzungseinheit hinaus global ist. Auch wenn es nicht automatisch in allen Einheiten sichtbar ist.
Man merkt das sehr schnell, wenn man in 2 Übersetzungseinheiten den gleichen Namen für verschiedene Variable verwendet. Wenn man die nicht mit 'static' auf diese Übersetzungseinheit beschränkt, raucht's .
Das der default für die Gültigkeit globaler Variablen ( oder besser allgemein 'Symbole' ) gleich 'linker-global' ist, dürfte nicht Allen bewusst sein.
Hanswurst123:
Ich glaube auch davon gelesen zu haben, dass es Variablen gibt, die nur für manche Funktionen sichtbar sind.
Da ist jetzt einiges an Informationen zusammengekommen.
Manchmal ist es tatsächlich leichter, aus Büchern oder durch selber suchen zu lernen statt zu fragen