Frage zu Visual C++

Soulmerge

Ich habe ein kleines, mit dem gratis-Compiler von Borland zusammengestelltes Projekt, das ich gerne ins Microsoft Visual C++ übertragen möchte. Die Dateien lassen sich ohne Probleme kompilieren, doch begreift der Microsoftsche Linker die Situation nicht ganz. Ich bekomme immer Fehlermeldungen Folgender Art:

Zitat

test2.obj : error LNK2005: "int i" (?i@@3HA) already defined in test1.obj

Die beiden Dateien, die hierfür kompiliert wurden:

Zitat

#ifndef TEST1_CPP
#define TEST1_CPP

#include "Test2.cpp"

#endif

Alles anzeigen

Zitat

#ifndef TEST2_CPP
#define TEST2_CPP

#include "Test1.cpp"

int i;

int main() {
return 0;
}

#endif

Alles anzeigen

Weiß irgendjemand, was man da machen kann?

thx

MichiK

header dateien verwenden:

in globalvar.h:

extern int i;

in globalvar.cpp:

static int i;

Soulmerge

Vielen Dank für die rasche Antwort, aber ich glaube, ich habe das Problem etwas zu stark verallgemeinert.
Das Problem wäre mit dem Integer anscheinend kein Problem, nur was mache ich, wenn mehrere Klassen habe, die sich gegenseitig inkludieren? Beispiel:

class A // in der Datei A.cpp
class AA : public A // inkludiert A.cpp
class AB : public A // inkludiert ebenfalls A.cpp

Wenn ich jetzt ein Programm schreibe, für das ich AA und AB inkludieren muss, so wirft mir der Linker einen Fehler entgegen, A wäre schon in AA definiert worden, und dürfte in AB.obj nicht noch einmal definiert werden.

Hoffe, das schildert die Situation etwas besser...

Ringding

Wenn du die .cpp Files inkludierst, kannst du auch nicht erwarten, ohne Probleme davonzukommen. Deklarationen nach .h, Code (außer Template-/Inline-Code) nach .cpp.

Soulmerge

Vielen Dank für eure Hilfe, habe das ganze schlussendlich in den c++ Builder von Borland gegeben und alles hat einwandfrei funktioniert. Ich habe mich anscheinend schon zu stark an die Borland FreeCommandLineTools gewöhnt, weiß nicht einmal, was verkehrt gewesen sein könnte. (Das mit Deklarationen und Implementierungen hatte ich in den richtigen Dateiendungen, habe anscheinend das Problem schon wieder zu stark abstrahiert)

lG, Soulmerge

marX

wenn so ein problem auftritt solltest du nicht einfach den compiler wechseln, sondern du solltest dich fragen, was du falsch gemacht hast:

.c oder .cpp files zu includieren ist ein GROBER felher!!!

kleiner tipp am rande:

header:
NUR deklarationen (und inline...)
am anfang ->
#ifndef FILENAME_H
#define FILENAME_H
... text ...
#endif
-> damit verhinderst du, dass der code (bei mehrmaligem includieren mehrmals durchlaufen wird.
-> vor alle variablen und fkt. muss (im header-file) "extern" gesetzt werden um dem compiler anzuzeigen, dass dieses symbol hier nur deklariert wird, der code aber in einer anderen datei folgt. (z.B. extern int i;)
im c/cpp file ganz normal (z.B. int i;)

was du aber gemacht hast, ist anstatt eines projekt-files alle c-files in eine datei zu includieren!!

ich kann dir aber nur raten dir einen "saubereren" programmierstiel anzugewöhnen!! sobald du mehr files hast wird das nicht mehr funktionieren bzw. deine info-lehrer werden verzeifeln
...außerdem ist visual c++ (meiner meinung nach) ein sehr guter compiler (entwicklungsumgebung)

Soulmerge

Danke für die Tipps. Nur noch einige Bemerkungen dazu:

Ich programmiere schon seit längerer Zeit kleinere Sachen mit dem kleinen Borland-Compiler, bis jetzt gab es für mich keinen Anlass auf eine Entwicklungsumgebung umzusteigen. Der Borland-Compiler hat anscheinend andere Konventionen als der von Microsoft. Der Code sollte theoretisch sauber sein (Alle Dateien enthalten #ifndef/#define/#endif, Deklarationen finden Ausschließlich in den Header-Dateien (Erweiterung '.h') und Implementierungen nur in .cpp-Dateien statt. Es wird keine Variable/Klasse/Enumeration mehr als einmal Deklariert/Implementiert und jede Klasse hat ihre eigenen Header/cpp -Dateien) Mittlerweile umfasst mein Projekt ca. 30 Dateien und ich arbeite immer noch mit der Borland-Entwicklungsumgebung und dem Command-Line-Compiler, da der Builder doch etwas zu lahm ist, wenn man nicht gerade am GUI-Teil herumbastelt.

Nur: Wenn ich das Projekt in den Visual C++ Compiler gebe, entsteht eben der oben genannte Fehler. Ein Grund könnte sein, dass ich am Ende meiner Header-Dateien die cpp-Dateien inkludiere, damit es wurscht ist, ob man von einer Anderen Stelle aus nun die Header-, oder die cpp-Datei inkludiert. (Obwohl ich selber nur die .h-Dateien inkludiere)

Ich sagte schon, ich habe das Problem sehr schlecht dargestellt, aber danke nochmal für die Sorge um meinen Programmierstil =)

Ringding

Was das Inkludieren von .cpp Files betrifft, verhalten sich eigentlich alle Compiler gleich (eine Ausnahme ist vielleicht Visual Age von IBM, aber das gibt's glaub ich schon lang nicht mehr). Wenn du mit VC++ auch nur das eine File ins Projekt geben würdest, das du mit dem BCC compilierst, dann würde auch das gleiche rauskommen. Umgekehrt würde sich der Borland Linker auch beschweren, wenn du jedes .cpp File compilieren würdest und danach alles zusammenlinken wolltest.

Soulmerge

Nein, das ist es ja, was ich am VC++ nicht verstehe: Beim Kompilieren gibt er überhaupt keine Fehler, nur beim Linken beschwert er sich, Definitionen von Klassenfunktionen wären mehrfach vorhanden (Die Definition einer Funktion f von A in B.obj, also: A::f already defined in B.obj ). Das Problem ist zwar nicht mehr so dringend, würde mich aber trtzdem interessieren, wie der auf so etwas kommt???

Ringding

Wenn du in zwei Übersetzungseinheiten eine Variable (oder Funktion) mit dem gleichen Namen anlegst und sie nicht extern oder static deklarierst, dann kollidieren die beiden beim Linken. So ist das nun mal in C.

Wenn du nun ein .cpp File inkludierst, werden alle Variablen, die darin angelegt werden, auch in der inkludierenden Übersetzungseinheit angelegt -> Clash.

marX

Zitat von Soulmerge

(Die Definition einer Funktion f von A in B.obj, also: A::f already defined in B.obj ). Das Problem ist zwar nicht mehr so dringend, würde mich aber trtzdem interessieren, wie der auf so etwas kommt???

Das passiert, weil du ja b.cpp in a.cpp inkludierst !!
=> VC++ übersetzt dann b.cpp nochmals (einzeln) und linkt dann a.obj und b.obj zusammen, was wiederum den fehler verursacht (die fkt. f wurde in beiden .obj dateien deklariert...)

mfg marX

Soulmerge

OK, ich habe hier mal ein kleines Test-Projekt geschrieben, dass sich mit VC++ _nicht_ übersetzen lässt. Könnte mir irgendjemand erklären, wieso? Mit den Borland-Tools funktioniert das einwandfrei, ich weiß wirklich nicht, woran das liegen könnte....

Ringding

Wie du hier siehst, geht es problemlos.

E:\Documents and Settings\Administrator\Desktop\test>cl /GX main.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

main.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:main.exe
main.obj

E:\Documents and Settings\Administrator\Desktop\test>main
9
8
E:\Documents and Settings\Administrator\Desktop\test>

Ringding

Wieso es mit deiner Methode nicht geht, haben wir jetzt schon dreimal geschrieben. Weil du mehrere Object-Files zusammenlinkst, deren Methoden sich teilweise überschneiden.

Deine #include-Struktur ist völlig schwachsinnig, sorry bitte es ist wirklich so.

Jedes .cpp File soll "sein" .h File inkludieren. Optional noch andere .h Files dazu.
Jedes .h File kann optional andere .h Files inkludieren.
Jedes .h File soll Include Guards haben (das hast du eh)
Ein .h File darf NIE ein .cpp File inkludieren.

Soulmerge

Einen Augenblick, bitte, das ist ein Programm, das *ich* geschrieben habe. Das ist einfach mein Programmierstil, und es lässt sich in *meinem* Visual C++ *nicht* kompilieren!!!! Also sagt mir nicht ständig, ich hätte ein Problem mit #includes, stattdessen wäre ein "Wahrscheinlich ist dein VC++ anders geconft" hilfreicher gewesen.

Zitat

Ein .h File darf NIE ein .cpp File inkludieren.

Wie gesagt: ich habe bis jetzt immer nur mit dem Borland command-line Compiler gearbeitet, und der schmeißt einen Fehler (hat er zumindest in früheren Versionen, beim neuen habe ich das nicht getestet), falls ich z.B. a.cpp nicht in a.h inkludiere und a.h aus einer anderen Datei inkludiert wird (Da ja die Implementierungen der Deklarationen fehlen, die in a.h stattfinden) -> Der compiler inkludiert keine Dateien in das Projekt, die nicht explizit in irgendeiner Datei inkludiert werden. Ich schätze mal in VC++ ist das anders. (Kann ich zumindest aus den bisherigen Antworten heraussieben.

Hier noch die Meinung von *meinem* VC++ zu dem kleinen Programm, dass ich geschrieben habe:

Zitat

--------------------Configuration: testtest - Win32 Debug--------------------
Compiling...
main.cpp
Linking...
Kuh.obj : error LNK2005: "public: __thiscall Tier::Tier(int)" (??0Tier@@QAE@H@Z) already defined in Bauernhof.obj
Kuh.obj : error LNK2005: "public: __thiscall Tier::~Tier(void)" (??1Tier@@QAE@XZ) already defined in Bauernhof.obj
Kuh.obj : error LNK2005: "public: class Tier & __thiscall Tier::fressen(class Futter)" (?fressen@Tier@@QAEAAV1@VFutter@@@Z) already defined in Bauernhof.obj
Kuh.obj : error LNK2005: "public: class Tier & __thiscall Tier::abnehmen(int)" (?abnehmen@Tier@@QAEAAV1@H@Z) already defined in Bauernhof.obj
Kuh.obj : error LNK2005: "public: class Futter __thiscall Tier::schlachten(void)" (?schlachten@Tier@@QAE?AVFutter@@XZ) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: __thiscall Tier::Tier(int)" (??0Tier@@QAE@H@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: __thiscall Tier::~Tier(void)" (??1Tier@@QAE@XZ) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Tier & __thiscall Tier::fressen(class Futter)" (?fressen@Tier@@QAEAAV1@VFutter@@@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Tier & __thiscall Tier::abnehmen(int)" (?abnehmen@Tier@@QAEAAV1@H@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Futter __thiscall Tier::schlachten(void)" (?schlachten@Tier@@QAE?AVFutter@@XZ) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: __thiscall Kuh::Kuh(int)" (??0Kuh@@QAE@H@Z) already defined in Kuh.obj
main.obj : error LNK2005: "public: class Futter __thiscall Kuh::melken(void)" (?melken@Kuh@@QAE?AVFutter@@XZ) already defined in Kuh.obj
main.obj : error LNK2005: "public: __thiscall Bauernhof::Bauernhof(void)" (??0Bauernhof@@QAE@XZ) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: __thiscall Bauernhof::Bauernhof(class Tier)" (??0Bauernhof@@QAE@VTier@@@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: __thiscall Bauernhof::Bauernhof(class std::vector<class Tier,class std::allocator<class Tier> >)" (??0Bauernhof@@QAE@V?$vector@VTier@@V?$allocator@VTier@@@std@@@std@@@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Bauernhof & __thiscall Bauernhof::erweitern(class Tier)" (?erweitern@Bauernhof@@QAEAAV1@VTier@@@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Bauernhof & __thiscall Bauernhof::erweitern(class std::vector<class Tier,class std::allocator<class Tier> > const &)" (?erweitern@Bauernhof@@QAEAAV1@ABV?$vector@VTier@@V?$allocator@VTier@@@std@@@std@@@Z) alre
ady defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Bauernhof & __thiscall Bauernhof::familienTreffen(void)" (?familienTreffen@Bauernhof@@QAEAAV1@XZ) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class Bauernhof & __thiscall Bauernhof::maesten(class Futter)" (?maesten@Bauernhof@@QAEAAV1@VFutter@@@Z) already defined in Bauernhof.obj
main.obj : error LNK2005: "public: class std::vector<class Tier,class std::allocator<class Tier> > __thiscall Bauernhof::alleViecher(void)const " (?alleViecher@Bauernhof@@QBE?AV?$vector@VTier@@V?$allocator@VTier@@@std@@@std@@XZ) already defined in B
auernhof.obj
Schwein.obj : error LNK2005: "public: __thiscall Schwein::Schwein(int)" (??0Schwein@@QAE@H@Z) already defined in main.obj
Schwein.obj : error LNK2005: "public: void __thiscall Schwein::grunzen(int)const " (?grunzen@Schwein@@QBEXH@Z) already defined in main.obj
Schwein.obj : error LNK2005: "public: __thiscall Tier::Tier(int)" (??0Tier@@QAE@H@Z) already defined in Bauernhof.obj
Schwein.obj : error LNK2005: "public: __thiscall Tier::~Tier(void)" (??1Tier@@QAE@XZ) already defined in Bauernhof.obj
Schwein.obj : error LNK2005: "public: class Tier & __thiscall Tier::fressen(class Futter)" (?fressen@Tier@@QAEAAV1@VFutter@@@Z) already defined in Bauernhof.obj
Schwein.obj : error LNK2005: "public: class Tier & __thiscall Tier::abnehmen(int)" (?abnehmen@Tier@@QAEAAV1@H@Z) already defined in Bauernhof.obj
Schwein.obj : error LNK2005: "public: class Futter __thiscall Tier::schlachten(void)" (?schlachten@Tier@@QAE?AVFutter@@XZ) already defined in Bauernhof.obj
Tier.obj : error LNK2005: "public: __thiscall Tier::Tier(int)" (??0Tier@@QAE@H@Z) already defined in Bauernhof.obj
Tier.obj : error LNK2005: "public: __thiscall Tier::~Tier(void)" (??1Tier@@QAE@XZ) already defined in Bauernhof.obj
Tier.obj : error LNK2005: "public: class Tier & __thiscall Tier::fressen(class Futter)" (?fressen@Tier@@QAEAAV1@VFutter@@@Z) already defined in Bauernhof.obj
Tier.obj : error LNK2005: "public: class Tier & __thiscall Tier::abnehmen(int)" (?abnehmen@Tier@@QAEAAV1@H@Z) already defined in Bauernhof.obj
Tier.obj : error LNK2005: "public: class Futter __thiscall Tier::schlachten(void)" (?schlachten@Tier@@QAE?AVFutter@@XZ) already defined in Bauernhof.obj
Debug/testtest.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
testtest.exe - 33 error(s), 0 warning(s)

Alles anzeigen

marX

Zitat von Soulmerge

Einen Augenblick, bitte, das ist ein Programm, das *ich* geschrieben habe. Das ist einfach mein Programmierstil, und es lässt sich in *meinem* Visual C++ *nicht* kompilieren!!!! Also sagt mir nicht ständig, ich hätte ein Problem mit #includes, stattdessen wäre ein "Wahrscheinlich ist dein VC++ anders geconft" hilfreicher gewesen.

es ist natürlich deine sache wie du programmierst, aber wenn du nicht auf "gute ratschläge" hören willst und deinen "programmierstil" behälst darfst du dich auch nicht wundern, wenn deine programme nicht funktionieren, bzw. sie sich nicht übersetzen lassen!

die methoden wie sie RingDing oben beschrieben hat werden von ALLEN verwendet, ganz einfach desshalb weil ALLE C/C++ Compiler auf diesen konventionen aufbauen!

dein "include-system" mag vielleicht mit diesem speziellen borland-compiler funktionieren, dieser wurde aber sicher nicht so entwickelt, dass es so gemacht werden muss!!! => kein anderer compiler (von dem ich je gehört habe) verwaltet projekte so => diese programme sind so desshalb auch nicht gerade portabel... (würde mich gerade interessieren, was POSIX dazu sagt ;))

das es mit *deinem* vc++ NICHT funktioniert hängt sicher nicht mit der conf. zusammen ... das würde HOFFENTLICH auch bei mir nicht funktionieren!! ich schätze mal als RingDing das test-prog. übersetzt hat verwendete er die "normalen" konventionen!

dies sollte KEIN angriff auf deine programmierfähigkeiten sein, aber wenn ich du wäre, würde mir doch überlegen ob ich nicht auf bewährte techniken zurückgreifen sollte...

mfg marX

Ringding

Das ist kein Stil, das ist ein Zustand!

Also jedenfalls funktioniert der Borland C++ Compiler genauso wie jeder andere auch. Du machst nur unterschiedliche Dinge in den beiden. BC hast du wahrscheinlich so verwendet: bcc32 main.cpp. Wie du oben gesehen hast, geht das mit VC++ auch. VC++ verwendest du hingegen von der IDE aus, wo du alle .cpp Files in ein Projekt gegeben hast. Daher werden alle übersetzt und am Ende zusammengelinkt -> Fehler. Würdest du das mit dem BC machen, würde er sich genauso beschweren. Wenn du es also weiterhin mit VC++ in der IDE compilieren willst, dann nimm alle .cpp Files bis auf das main.cpp aus dem Projekt raus, dann müsste es gehen.

Soulmerge

OK, vielen dank, der letzte Post war es, den ich gebraucht habe. Ich werde es mal damit probieren, und versuchen, mir klarzumachen, dass ich die cpp's nicht inkludieren muss...
Vielen Dank für die zahlreichen Antworten...
lG, Soulmerge

Übrigens: in Borland IDE kann man genauso gut alle Dateien zu einem Projekt inkludieren und ohne linker-Fehler kompilieren, daher mein Unverständnis zur VC++ Interpretation

Ringding

Ich glaub bei Borland gibt der Linker nur eine Warning, wenn was doppelt definiert ist. Und selbst die kann man ausschalten (-wdup bzw. -wdpl)

Jetzt mitmachen!