Fehler bei Plugins

[Moppi]

Hallo,

zurzeit arbeite ich mit ausgelagertem Code in C- und CPP- Dateien.

Wenn ich denselben Code verwende (oder dieselben Bezeichner für Variablen bspw.), aber in Dateien mit unterschiedlichen Namen, bekomme ich dennoch solche Fehler:

sketch\myServo.cpp.o (symbol from plugin): In function `ms':


(.text+0x0): multiple definition of `Area1BeginValue'


sketch\myAdafruit_PWMServo.cpp.o (symbol from plugin):(.text+0x0): first defined here

Natürlich am Ende mit : exit status 1


Kann man das irgendwie abstellen?
Also z.B. `Area1BeginValue' istnur einmal im Sketch definiert, weil ja nur eine Datei von beiden in den Sketch eingebunden wird, nicht beide zur selben Zeit. Aber weil die IDE beide Dateien findet, beschwert sie sich, dass ich dieselbe Bezeichnung darin verwende.


MfG

[Ceos]

das ist normal, deswegen verwendet man auch scoping und include guards in den header dateien

der einzige weg das ab zu stellen wäre die variable korrekt zu definieren, nämlich in einem headerfile

oder es in allen bis auf einer datei als extern zu deklarieren (ist aber eher bad practise)

(Schau dir mal das schlüssselwort extern genau an, das hat seine zwecke aber nciht unbedingt dafür)

[Moppi]

Also muss man mit Compilerdirektiven den Code noch etwas unübersichtlicher machen. Das ist eine der Sachen, die ich gar nicht leiden mag.

PS: Header Dateien sind nat. auch da.

MfG

[Ceos]

das könnte ich genau so zurückgeben, code bei dem variablen nahezu identisch heißen und verstreut übr den code quer durchs programm deklariert werden sind genau so unübersichtlich ...

c ist nun halt mal so aufgebaut dass es gewisse regeln gibt damit der compiler es eineindeutig verstehen kann ... und das trägt auch der lesbarkeit zu ... wenn alle variablen in den entsprechenden header files des jeweiligen modul liegen und dabei sogar noch sauber zwischen public und private headern sortiert gearbeitet wird, ist es unmöglich mal "zufällig" den selben variablennamen mit unterschiedlichen typen zu deklarieren, denn jede c datei eines moduls inkludiert nur die public und die private header die für die verwendung notwendig sind!

in richtigem c++ sind variablen in den klassen zu deklariern und wenn man mal eine globale variable braucht, sollte man eine klasse darum wrappen und mit sog. singelton (oder statisch) arbeiten ...
man kann c++ und c mischen aber das ist grausig und führt zu nebeneffekten

PS zu deinem PS: Include Guards für C++ sind aber der absolute Standard in jeder IDE soweit mir das bekannt ist

[Moppi]

Ja, das ist das leidige Thema mit C.

Normal ist eigentlich der Zustand, den Programmcode auszuwerten, der zu einem Programm gehört, also in einem Sketch hier bspw. eingebunden ist. Nur der ist zu berücksichtigen. Nicht Code in Dateien, der sonst irgendwo, vielleicht sogar noch im Internet (etwas übertrieben) zu finden ist.

Solche Praktiken wie in C/C++ sind einfach nervig und erschweren das Programmieren unnötig. Die Fehlersuche nachher ebenfalls, weil man sich nicht nur durch den Programmcode lesen muss, sondern auch noch berücksichtigen muss, welche Direktiven für den Compiler in einem bestimmten Fall greifen. Aber das wird sich wohl nie mehr ändern.
Es spricht absolut nichts dagegen, wenn man zwei Lösungen in einzelnen Bibliotheken, jeweils für sich, hinterlegt. Einmal für den einen Fall, einmal für einen anderen Fall. Man bindet nur die Bibliothek ein, die man benötigt und gut ist. Das Vermengen von zwei Bibliotheken in eine einzige und die Unterschiede in der Anwendung mit Direktiven zu steuern, trägt nicht zur Übersichtlichkeit bei. Beim MASM und TASM war das auch schon möglich, habe ich aber nie verwendet, genau aus dem Grund, weil es zur Verwirrung bei der Fehlersuche führt und die damit unnötig erschwert. Aber ich kann es eh nicht ändern. Nehme dann den Texteditor und benenne kurzerhand in einigen Schritten alle Variablen um, indem sie vorangestellte Zeichen erhalten. So ist es in den Bibliotheken wieder unterschiedlich und eindeutig.



MfG

- - - Aktualisiert - - -

Na ja, wer sagt's. Ist erledigt.


MfG

[Ceos]

Aber das wird sich wohl nie mehr ändern

schonmal python ausprobiert? oder eine der neuen programmiersprachen?

ich bin ein totaler fan von micropython und such schon die ganze Zeit nach einem brauchbaren STM32F103 Board mit mehr als 512k Flash

ich habe zwar gerade erst von den entwicklern eine version für die nucleol432kc boards mit 256k speicher bekommen aber da fehlt so viel zeug und auch der USB also taugt das auch nciht für meine low power pläne, zumal auf dem uncelo noch ein F103 als debugger steckt, der 4 mal so viel frisst wie der L432 auf dem der egentliche code rennt

ich mach m,al ein topic hier auf, weil mir das echt unter den fingern brennt und cih beim suchen an meine grenzen stoße

[HaWe]

Ja, das ist das leidige Thema mit C.
Solche Praktiken wie in C/C++ sind einfach nervig
MfG

Arduino verwendet nun mal C++, nichts anderes (auch kein "reines" ANSI C99), und der C++ Compiler ist von gnu (gcc/gpp), der ist internationaler Standard und entspricht auch voll den C++11 Konventionen (irgendwann auch C++14).
So ist C++ nun eben mal, auch was .h und .cpp angeht (nur dass diese source files hier unter Arduinorianern fälschlich als "libraries" bezeichnet werden, was sie nicht sind - libraries in C/C++ sind kompiliert und enden auf .so )

[Ceos]

nur dass diese source files hier unter Arduinorianern fälschlich als "libraries" bezeichnet werden, was sie nicht sind - libraries in C/C++ sind kompiliert und enden auf .so

Wo hast du denn diese hanebüchene Definiton her !? Kennst du den Begriff Quelltextbibliothek?!

In dem Kontext gefragt, was ist eine DLL für dich ?

das precompilat ist einfach nur ungleich kompakter und wird deswegen bevorzugt ... jede Sammlung von Funktionen und Konstanten kann man als Bibliothek in der Programmierung bezeichnen, die Speicherform ist dabei unerheblich

By the way, könnte man dir die Board Files auch al .s / .so zur Verfügung stellen, dann wärst du aber angeschmiert, wenn du etwas dran ändern willst, daher wir die Library(Bibliothek) als Quelltext angeboten

[HaWe]

diese "hanebüchene" Definition habe ich aus dem Raspberry-C++ Forum.
edit: ich vergaß oben neben den dynamischen (.so) auch die statischen Libraries zu erwähnen, die auf .a enden
.h mit ihren .c/.cpp files werden nicht als Libraries bezeichnet, sie befinden sich auch an anderer Stelle als die Libraries.

Hierzu stehen Ihnen zwei Möglichkeiten zur Verfügung – das Erstellen einer statischen oder einer dynamischen Bibliothek.

http://openbook.rheinwerk-verlag.de/...00061A1F029102
http://openbook.rheinwerk-verlag.de/...00061A1F02917F
Ich will es aber auch gar nicht ändern, wie kommst du darauf - ich wollte nur auf den anderen Sprachgebrauch aufmerksam machen.
War hier aber auch nur eine Randbemerkung.

Die wesentliche Aussage war:

Arduino verwendet nun mal C++, nichts anderes (auch kein "reines" ANSI C99), und der C++ Compiler ist von gnu (gcc/gpp), der ist internationaler Standard und entspricht auch voll den C++11 Konventionen (irgendwann auch C++14).
So ist C++ nun eben mal, auch was .h und .cpp angeht

[Moppi]

In der Arduino -IDE kann man Bibliotheken importieren/einbinden.
So weit ich sehen kann, bestehen die Bibliotheken aus einer CPP-Datei, einer H-Datei und einer Beschreibungsdatei "library.properties".



MfG