Hallo Leute solange ich alles im Main File hatte kein Problem
dann lagerte ich die Funktionen in einen Header und
cpp File aus und bekomme folgendes
der compiler schreibt eine exe Datei mit dem Namen des Headers und c++
MyStrings.exe obwohl das Project Test1 heiß und er auch Test1.exe
geschrieben hat.
Bitte nicht schimpfen ich komme aus der Pascal Welt und programmiere in
C weil ich gerne Arduinos programmiere ESP32 besser gesagt
> Executing task: C:\MinGW\bin\g++.exe -g d:\projects\test1\Test1.cpp -o
d:\projects\test1\Test1.exe <
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe:
C:\Users\ats37\AppData\Local\Temp\cc0PWW65.o: in function
`Z8DoJobIniPcS_':
d:/projects/test1/Test1.cpp:69: undefined reference to `StrPos(char*,
char*)'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe:
d:/projects/test1/Test1.cpp:71: undefined reference to `StrDel(char*,
int, int)'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe:
d:/projects/test1/Test1.cpp:74: undefined reference to `StrPos(char*,
char*)'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe:
d:/projects/test1/Test1.cpp:76: undefined reference to `StrCopy(char*,
int, int)'
collect2.exe: error: ld returned 1 exit status
The terminal process terminated with exit code: 1
Terminal will be reused by tasks, press any key to close it.
Das undefined undefined reference passiert nach dem Kompilieren, beim Linken. Es bedeutet, dass das symbol nirgens gefunden wurde, in keinem der Objekte, und in keiner Library (wobei bei letzterem auch die Reihenfolge eine rolle spielen kann). Im Beispiel hast du keine Libraries (ausser implizit die libc) oder sonstigen Objekte, du hast nur die Test1.cpp Quelldatei, die du in einem Schritt zu kompilieren und linken versuchst. Offenbar enthält diese aber keine Definition für u.a. die Funktion "StrCopy(char*, int, int)", deshalb gibt es das Symbol nicht, und kann beim linken auch nicht gefunden werden. Übrigens, für z.B. strpos, da gibts schon was vergleichbares in der libc / standard library. http://www.cplusplus.com/reference/cstring/strstr/
Ich vermute, dass die Str..() Funktionen, die ausgelagerten sind? Du sagst dem GCC, dass er die Datei Test1.cpp kompilieren soll und ein Programm Test1.exe erstellen soll (das dann aber der Linker macht). Die Errors kommen auch von dem Linker. Der Kompiler kennt die Definition der Funktionen aus der Header Datei. Beim "Zusammenbauen" der Exe fehlt aber die Deklaration (in der neuen cpp). Du musst also noch die andere cpp kompilieren und dann beide ObjektDateien zusammen linken. Suche mal nach Makefile.
Ein fehlender prototype ist in C++ aber Fehler, das meckert schon der Compiler an. Dann wurden die Funktion vorher deklariert, aber beim Linken fehlt das obj mit dem Code.
Beim gcc, sowie beim clang, ist die Option um ein ".o" file zu erhalten übrigens "-c".
1 | gcc a.c -c -o a.o |
2 | gcc b.c -c -o b.o |
3 | gcc a.o b.o -o prog.exe |
Den Zwischenschritt kann man zwar auch den GCC implizit machen lassen, das hier tut das selbe:
1 | gcc a.c b.c -o prog.exe |
Man muss immer alle relevanten Dateien angeben, die werden nicht automatisch gesucht.
Ganz lieben dank, aber dafür bin ich zu blöde. In Delphi gibt es so einen Mumpitz nicht.
Martin M. schrieb: > Ganz lieben dank, aber dafür bin ich zu blöde. > In Delphi gibt es so einen Mumpitz nicht. modules!
Oliver S. schrieb: > Sicher gibts das da ganz ähnlich. die C Kompiler/Linker Meldungen, Konventionen usw. sind in Delphi schon ganz anders - die Sprache hat Module, kennt Library und Application im Sprachstandard - d.h. viele Build-Probleme existieren in Delphi so gut wie gar nicht, und die Orgien an Fehlermeldungen sind auch eher eine C/C++ Sache
cppbert schrieb: > Oliver S. schrieb: >> Sicher gibts das da ganz ähnlich. > > die C Kompiler/Linker Meldungen, Konventionen usw. sind in Delphi schon > ganz anders - die Sprache hat Module, kennt Library und Application im > Sprachstandard - d.h. viele Build-Probleme existieren in Delphi so gut > wie gar nicht, und die Orgien an Fehlermeldungen sind auch eher eine > C/C++ Sache Weswegen C++20 diese Technik übernehmen will, ohne die Nachteile der "Vorlage" zu erben.
Wenn es nichts geheimes ist, dann lade doch Mal die Header- und Sourcedatei hoch. Vielleicht ist es auch ein Fehler, den du nicht siehst.
Carl D. schrieb: > cppbert schrieb: >> Oliver S. schrieb: >>> Sicher gibts das da ganz ähnlich. >> >> die C Kompiler/Linker Meldungen, Konventionen usw. sind in Delphi schon >> ganz anders - die Sprache hat Module, kennt Library und Application im >> Sprachstandard - d.h. viele Build-Probleme existieren in Delphi so gut >> wie gar nicht, und die Orgien an Fehlermeldungen sind auch eher eine >> C/C++ Sache > > Weswegen C++20 diese Technik übernehmen will, ohne die Nachteile der > "Vorlage" zu erben. Es ist nur schade das die C++-Komitte so lange gebraucht hat diese Manko wenigstens mal als solches zu akzeptieren - jetzt wird schon bestimmt seit 4 Jahren an einer Lösung gedoktert und es gibt viele kleine Schwächen -Initiale Builds langsamer weil die Module erst vollständig erzeugt werden müssen -> Zwangsserialisierung des Builds (mit Header+Cpp ist das einfach egal und dann schreit eben der Linker später) -Kein Konzept damit ein Build-System leicht erkennen kann ob ein Modul-Inteface Änderung ein Neubau des hinterliegenden Codes benötigt - bisher wurde da einfach aufs Dateidatum geschaut, das reicht jetzt nicht mehr und die Build-Systeme müssen weiterhin allerlei Tricks machen und das sauber zu lösen es gibt einige Leute im Komitee die mit dem aktuellen Stand nicht zufrieden sind...
und solche Problem hat Delphi z.B. nicht weil der Kompiler und Linker keine getrennten Einheiten sind - und C-Linkage ist was besonderes, das gesondert behandelt wird, einfach viel weniger Einschränkungen um das Performant zu bekommen, bei Java und .Net genau so
Trotzdem viele vielen Dank
Für meine Arduino Projekte reicht meine C++ Kenntnisse,
ich kann einfache Objekte schreiben und PlatformIO die komfortable IDE
nimmt das linken der Objekte etwas gelassener.
Hatte in den 80 die Möglichkeit Pascal oder C zu lernen ich hatte mich
für Pascal entschieden und wenn ich beide Sprachen vergleiche ist Pascal
die bessere Sprache man hätte einiges ändern können modernisieren was
ich an Post Pascal Sprachen mag sind die {} für begin und end. Oh ich
bin abgeschweift sorry
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.