Funktion aus Funktion aufrufen die sich in einer Include Datei befindet

Hast Du das h-File dort includiert, wo Du es aufrufst?

Gib uns doch mal ein Beispiel (mit den zugehörigen Dateien in Codetags) wo es klemmt.

Gruß Tommy

Genau!
Zeige es.

Alternativ:
Dickes C++ Buch anschaffen!
(was sowieso ein guter Tipp ist! ...denke ich mal...)

Include scheint mehr zu sein als einfach nur Funktion um Code nachzuladen.

Nach meinem Verständnis sollte es eher weniger sein.
( Deklaration von Funktionen, Datentypen, usw. , damit .cpp Dateien schonmal übersetzt werden können, bevor der Linker alles zusammenfügt)

Der Fehler "not declared in this scope" stammt übrigens vom Compiler, nicht vom Linker.

Das mit dem dicken C++ Buch ist zwar ein guter Tip, kommt aber nicht so sehr aufs "Anschaffen", sondern eher aufs "Einsteigen" an, was zur Not auch ohne Buch geht.

Grundsätzliche Sachen versteht man (ich zumindest) übrigens besser an einem möglichst kleinen Beispiel.

Funktionen gehören nicht in Header-Dateien (.h) sondern in Code-Module (.cpp), In die Header-Datei kommt nur die Deklaration der Funktion, ohne Code.

Nicht ganz richtig.
Vielleicht meistens, aber nicht zu 100%

Bei dem Paradigma verdirbt es einiges.
z.B. ausgelagerte Inline Funktionen.

DrDiettrich:
Funktionen gehören nicht in Header-Dateien (.h) sondern in Code-Module (.cpp), In die Header-Datei kommt nur die Deklaration der Funktion, ohne Code.

Das ist für den größten Teil aller Funktionen zwar richtig, aber Combie weist auf wichtige Ausnahmen hin. Kurze Funktionen, die „inline“ compiliert werden sollen (die keinen Funktionsaufruf mit allen „Nebenwirkungen“ zur Folge haben sollen), sind in Header-Dateien vollkommen in Ordnung (zum Beispiel get-Methoden in Klassen).

Gruß

Gregor

Eine Funktion, die inline realisiert werden soll, kann natürlich nicht woanders definiert sein als in der Datei (oder einer dort includierten), wo sie verwendet wird.

Deshalb haben manche Compiler die Voreinstellung, dass Funktionsdefinitionen in .h Dateien inline realisiert werden, aber eigentlich sind das verschiedene Sachen.

Oft ist es auch Faulheit (und damit verständlich aber unentschuldbar), für Funktionsdefinitionen keine eigene .cpp Datei anzulegen.

Betrifft ja nicht nur inline Code.

Auch Konstanten.

In C Stil, würde man sich eine config.h anlegen und da "#define led 13" rein schreiben.
Und wo man die Led braucht, dann eben #include "config.h"

Fast ist die Welt damit in Ordnung, aber leider keine Typeprüfung, und eine evtl. geworfene Fehlermeldung bezieht sich auf Code, welchen man so nicht im Quelltext vorfindet.(wo kommt diese doofe 13 her?)

Darum wurde const erschaffen.

Ein einfaches "const byte led=13;" macht einen auch nicht glücklich, wenn die *.h Datei mehrfach verwendet werden soll.

Aufteilen in "extern const byte led;"(in der *.h) und const byte led=13; (in der *.cpp), würde uns vor Meldungen schützen, birgt aber das Problem in sich, dass der Compiler dem Linker eine Adresse der Konstanten mitteilen muss.
Damit braucht sie Speicher, und kann nicht weg optimiert werden.

Ein "static const byte led=13;" (in der *.h) würde das Problem lösen.


Kann nicht mal einer ein ordentliches Tutorial dazu schreiben?
z.B. "Das Arduino und seine Tabs"
Oder "Code sinnvoll aufteilen"
:o :o :o :o

michael_x:
...
Deshalb haben manche Compiler die Voreinstellung, dass Funktionsdefinitionen in .h Dateien inline realisiert werden, aber eigentlich sind das verschiedene Sachen.
...

Soweit ich weiß, ist ein Compiler, der Definitionen in Header-Dateien nicht inline compiliert, nicht konform zum Standard.

Wie meinst Du das „eigentlich“?

Gruß

Gregor

combie:
...
Kann nicht mal einer ein ordentliches Tutorial dazu schreiben?
z.B. "Das Arduino und seine Tabs"
Oder "Code sinnvoll aufteilen"
...

Das sind zwei Themen, die sich für eine Weekenderei eignen würden. Jetzt habe ich bereits vier weitere Themen. Was fehlt, ist der Schreibanfall :slight_smile:

Gruß

Gregor

Bei C++ gibt es mehr Standards als Compiler, die ich kenne :wink:
In welchem Standard jetzt vorgeschrieben ist, dass Funktionsdefinitionen in .h Dateien inline realisiert werden müssen, und/oder wie man das dem Compiler zur Optimierung selbst überlassen kann, ist mir jetzt zu mühsam nachzulesen.

Wie meinst Du das „eigentlich"?

  • inline als Schlüsselwort kannst du mit und ohne .h Datei verwenden.
  • In .h Dateien definierte Funktionen werden wohl bei mehrfacher Verwendung und entsprechender Größe nicht inline realisiert. (Bei Arduino wird sinnvollerweise auf Speicherplatz optimiert)

michael_x:
Bei C++ gibt es mehr Standards als Compiler, die ich kenne :wink:
In welchem Standard jetzt vorgeschrieben ist, dass Funktionsdefinitionen in .h Dateien inline realisiert werden müssen, und/oder wie man das dem Compiler zur Optimierung selbst überlassen kann, ist mir jetzt zu mühsam nachzulesen.

Ich meine ISO-C++. Frag' mich jetzt aber bitte nicht nach Quellen :slight_smile:

michael_x:
[eigentlich ...]

Stimmt. So kapiere ich das.

Gruß

Gregor

Hallo,

also um es kurz zu machen .... ääääääääääää das soll also heisen das ich C++ lernen muss um
Funktionen auszulagern ?????? Das muss doch einfacher gehen. Der Compiler muss doch nur alle nachzuladenden Teile als Temporär zusammenfügen.

Geuss TFT

Oder Du machst es so, wie es schon bei K&R gemacht wurde und heute noch funktionieren muß:

Deklaration (ohne Code) in *.h, Definition (mit Code) in *.cpp.

temucin:
Hallo,

also um es kurz zu machen .... ääääääääääää das soll also heisen das ich C++ lernen muss um
Funktionen auszulagern ?????? Das muss doch einfacher gehen. Der Compiler muss doch nur alle nachzuladenden Teile als Temporär zusammenfügen.

Geuss TFT

Der Compiler macht genau das, was Du ihm sagst - nicht das, was Du von ihm willst.
Also ja, Du solltest C/C++ lernen.

Gruß Tommy

temucin:
also um es kurz zu machen .... ääääääääääää das soll also heisen das ich C++ lernen muss um
Funktionen auszulagern ?????? Das muss doch einfacher gehen.

Ja, das Autofahren geht auch leichter, wenn man die Bremse ignoriert :wink:

temucin:
Der Compiler muss doch nur alle nachzuladenden Teile als Temporär zusammenfügen.

Das tut er auch, wenn Du es ihm sagst, auf die eine oder andere Art.

Was das mit der Standardkonformität angeht: Ich war inzwischen mehrmals froh, dass ich meine Lieblings-Bibliothek auf Standard-PC, Rasperry Pi und Arduinos einsetzen konnte. Mit Compiler-spezifischen Eigenheiten oder Abhängigkeiten von anderen (fremden) Bibliotheken hätte ich mir höllisch mit #ifdef- und #ifndef-Zeug ins Knie schießen müssen. So war das lediglich eine harmlose Datei-Kopiererei.

Gruß

Gregor

Mein Oma hatte bei solcherart Problemen immer einen Spruch auf ihrer spitzen Zunge:

Wasch mir den Pelz, aber mach mich nicht nass.

https://forum.arduino.cc/index.php?topic=512363.0

Hi ... der Link war lehrreich. Auch meine Psyche geht es jetzt gleich viel besser :slight_smile:

Danke , Gruss TFT