Fehler bei Plugins

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:

Code:

---

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

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)

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

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

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

Zitat:

---

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

Zitat:

---

Zitat von Moppi

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 8) )

Zitat:

---

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 8)

---

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

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.

Zitat:

---

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:

Zitat:

---

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

---

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

ja, genau so ist das bei Arduino, das sind spezielle Konventionen.
Was aber die grundsätzlichen Anforderungen an #include-te .h oder .cpp Files angeht, das ist bei Arduino absolut C++- standardgemäß, das hat Ceos ja bereits geschrieben:

Zitat:

---

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

---

ninja im computing sprachgebrauch ist der begriff bibliothek oder library zeimlich genau festgelegt und der schert sich nicht um die speicherform, aber den begriff auf wenige speicherarten zu begrenzen passt da jedenfalls überhaupt nicht hin, alles was vorne in einen compiler reingeht und eine sammlung von nicht eigenständig lauffähigen funktionen darstellt ist per (im computing gebräuchlicher) definiton eine bibliothek, ich wollte hier nur auf einen fehler deinerseits hinweisen und nehme das "hanebüchen" zurück, das war nicht nett formuliert

ich wollte nur überspitzt darauf hindeuten dass es zu kurz gegriffen ist (wir hatten das thema schon in einem deiner topics ausgebreitet, aber jetzt verstehe ich deine perspektive darauf und du hoffentlich meine, warum arduino auch im grunde nur eine library ist)

ja, klar!
In der gedrängten Kürze eines Forumsposts kommt es manchmal eben leider auch mal nur verkürzt an, was man eigentlich meinet ;)

In der Arduino-IDE sind Files für eine Bibliothek die H-Datei, die CPP-Datei und eine Beschreibungsdatei.

Ich habe jetzt diese Files in ein ZIP-File gepackt, um es in der IDE importieren zu können. Ich erhalte viele Fehler, aber importiert wurde es dennoch und steht jetzt im Menü bei Bibliotheken drinnen.

Code:

---

java.util.zip.ZipException: error in opening zip file    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:225)
    at java.util.zip.ZipFile.<init>(ZipFile.java:155)
    at java.util.zip.ZipFile.<init>(ZipFile.java:169)
    at processing.app.tools.ZipDeflater.<init>(ZipDeflater.java:26)
    at processing.app.Base.handleAddLibrary(Base.java:2278)
    at processing.app.Base$6.actionPerformed(Base.java:1085)
    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
    at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
    at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
    at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
    at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
    at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
    at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
    at java.awt.Component.processMouseEvent(Component.java:6533)
    at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
    at java.awt.Component.processEvent(Component.java:6298)
    at java.awt.Container.processEvent(Container.java:2236)
    at java.awt.Component.dispatchEventImpl(Component.java:4889)
    at java.awt.Container.dispatchEventImpl(Container.java:2294)
    at java.awt.Component.dispatchEvent(Component.java:4711)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
    at java.awt.Container.dispatchEventImpl(Container.java:2280)
    at java.awt.Window.dispatchEventImpl(Window.java:2746)
    at java.awt.Component.dispatchEvent(Component.java:4711)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90)
    at java.awt.EventQueue$4.run(EventQueue.java:731)
    at java.awt.EventQueue$4.run(EventQueue.java:729)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
error in opening zip file

---

Wäre schön, wenn ich wüßte, was die Fehler bedeuten und wie man sie beseitigt.

MfG

hm - du brauchst "Libraries" nicht über diesen Umweg als .zip file einbinden.
Das Aduino-Wiring-Java der IDE erwartet evtl. noch ein paar Besonderheiten.
Es reicht, wenn du sie ganz einfach in den libraries Unterordner hineinkopierst, wobei der library_Name nur identisch sein muss dem Namen des wesentichen .h files.
Nur reinkopieren - fertig.

Ja, stimmt. Danke für den Hinweis, HaWe!

MfG

Zitat:

---

error in opening zip file

---

ich vermute mal du hast nicht windows zip sondern 7zip oder winrar benutzt, die benutzen nicht immer ganz konforme formate manchmal

aber wie HaWe schon sagte, zum einbinden reicht es einfach die Dateien per add file hinzuzufügen oder die dateien direkt neben die ino zu kopieren, von da aus sollte allse automatisch im suchpfad für includes liegen

Ich habe das ZIP-File repariert, nun klappts auch ohne Fehler. \\:D/
Ja, winrar.


MfG

Zitat:

---

Zitat von Moppi

Ich habe das ZIP-File repariert, nun klappts auch ohne Fehler. \\:D/
Ja, winrar.
MfG

---

nur noch ein Tipp (wieder mal am Rande)...
Falls du es noch nicht nutzt...:

falls du viele selbsterstellte und 3rd-Party Libraries benutzt, und auch öfter mal upgradest von einer Arduino-IDE zur nächsten Version, dann macht es Sinn, mit der "portable" Version zu arbeiten.
Hier werden die von dir neu hinzugefügten Libs getrennt von den original-Arduino-Libs verwaltet (auch neue Board-Cores etc.), und wenn du die IDE upgradest, brauchst du nur den alten portable Ordner wieder in die neue IDE hinüberzukopieren.
Dann sparst du dir auch das Neuinstallieren von Boards.

Dazu sollest du allerdings zuvor deine eigenen Libs im Sketchbook-Ordner und im Haupt-Libraries-Ordner sichern,
eine von Arduino erstellte Version im Programmordner über Windows komplett deinstallieren
und dann die portable-Version ("non-admin-installation") neu herunterladen - und am besten nicht nach C:\Programme, sondern nach D:\ entpacken, wegen Zugriffsrechten.
Dann im Arduino-Ordner einen Unterordner "portable" erstellen.
Dann die Arduine IDE starten und wieder beenden.

Dann findest du im Ordner portable u.a. einen Unterordner "sketchbook",
darin einen Unterordner "libraries",
und dahin gehören jetzt deine eigenen Libs.

Künftig brachst du dann immer nur diesen "portable" ordner von einer IDE zur nächsten rüberkopieren, das macht viel weniger Arbeit bei Updates oder wenn du es auf ganz anderen PCs nutzen willst.

https://www.arduino.cc/en/Guide/PortableIDE

Auch gut zu wissen, danke!

MfG