Dieser verdammte Linker macht mich wahnsinnig

[MrSm!th]

So, nach langer Zeit muss ich hier auch mal wieder was posten

Ich entwickle derzeit die Gamehacking Foundation, die ich hier schonmal vorgestellt hatte.

Momentan macht mich der Linker bei meinem Testprojekt für die Klasse GHF::String fertig.

#include <windows.h>
#include <iostream>
#include <GHF\GHF.h>

#pragma comment (lib, "GHF.lib")


int main()
{
	GHF::String s = "hi";
	GHF::String s2 = L"hi";

	s = s+s2;
	std::cout << s.c_str() << std::endl;
	

	system("pause");
	return 0;
}

Ist schon der ganze Code.

GHF::String GHF::operator+(GHF::String const  &s1, GHF::String  const &s2)
{
	GHF::String tmp = s1;
	tmp += s2;
	return tmp;
}

Ist der Code der Operatorenüberladung für GHF::String,GHF::String

Fehlermeldung:

1>------ Erstellen gestartet: Projekt: ghfdetourtest, Konfiguration: Release Win32 ------
1>Der Buildvorgang wurde am 09.11.2010 21:24:57 gestartet.
1>InitializeBuildStatus:
1> Aktualisieren des Timestamps von "Release\ghfdetourtest.unsuccessfulbuild".
1>ClCompile:
1> main.cpp
1>main.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""class GHF::String __cdecl GHF:: operator+(class GHF::String const &,class GHF::String const &)" (??HGHF@@YA?AVString@0@ABV10@0@Z)".
1>G:\Dokumente und Einstellungen\Nico\eigene dateien\visual studio 2010\Projects\ghfdetourtest\Release\ghfdetourtest. exe : fatal error LNK1120: 1 nicht aufgelöste externe Verweise.
1>
1>Fehler beim Erstellen
1>
1>Verstrichene Zeit 00:00:00.93
========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ==========

Ich verstehe einfach nicht, was er von mir will.

int main()
{
	s += s2;
	std::cout << s.c_str() << std::endl;
}

Das klappt super und die beiden Strings werden komplett aneinandergehangen.


Damit ich direkt meine zweite Frage loswerden kann:

Die GHF soll eine statische lib werden.
Normalerweise würde ich die STL Lib auch statisch reinlinken, damit ich die Redistributables nicht ausliefern muss, leider macht der Linker dann Stress, wenn ich die GHF in ein anderes Projekt linke, dass die STL auch statisch gelinkt hat.
Dann erzählt er mir nämlich was von Neudefinitionen.
Wenn ich die STL in der GHF statisch linke und im Projekt dynamisch, gehts, leider brauchen die Nutzer die Redistributables, ansonsten lässt sich das Programm nicht starten.

Meine Frage wäre nun:

Wenn ich die STL dynamisch in der GHF linke und im Projekt, in dem ich sie nutze, die STL statisch linke, werden dann die Leute trotzdem die Redistributables brauchen, weil die STL ja in der GHF dynamisch gelinkt ist oder werden die Calls aus der obj Datei der GHF dann auf die statisch gelinkte STL umgeleitet, anstatt auf Dlls?

Falls nicht, heißt das ja, dass ich die GHF nicht zu einer statischen lib machen kann, ohne die Redistributables ausliefern zu müssen, weil ich sie entweder in der GHF oder im Endprojekt dynamisch linken muss <.<


Ich nutze btw. Visual Studio 2010 Professional


Wäre schön, wenn mir da wer helfen könnte

[Bot_interesierter]

Exportierst du auch brav die Symbole in deiner Lib?
Denn das sieht mir schwer danach aus das die Symbole nicht aufgelöst werden können, da sie schlicht nicht Exportiert wurden.

[MrSm!th]

Aber der operator+= wird doch auch exportiert, ohne das ich ihn speziell deklariere oder etwas an den Einstellungen aendere.
Also wie meinst du das, wie soll ich sie denn exportieren?

Kannst du mir auch bei der ersten Frage helfen?

[Bot_interesierter]

Ohne das Library Projekt wird es schwierig die genaue Ursache herauszufinden.
Du kannst mir auch ein Miniprojekt machen das den Fehler reproduziert, würde ich mir dann gerne mal anschauen.
Ich kann mir eigentlich nur vorstellen das irgendwelche Projekt Einstellungen nicht stimmen und daher das Symbol, zumindest nicht wie erwartet vorhanden ist.

[MrSm!th]

Ok, da die GHF eh open source wird, kann ich sie mig dem test hochladen

edit:

hochgeladen

du müsstest die GHF einmal kompilieren, da die lib grad nicht im release ordner ist
wie gesagt, operator+= kann ich verwenden, der ist member der klasse.
operator+ ist kein member, sondern global überladen. könnte es daran liegen? kann ich mir aber irgendwie nicht vorstellen, wenn ich funktionen im header deklariere oder klassen, werden sie auch exportiert, warum dann der global überladene operator+?

ach ja, erstmal nichts zur performance der string klasse sagen, erstmal soll sie funktionieren, dann kann ich mich um eine effiziente implementierung kümmern und das ziel von GHF::String ist auch hauptsächlich, möglichst kompatibel zu anderen Strings zu sein und eine Vielzahl an Stringmanipulationen zu bieten.

GHF:




Test Projekt:



Sorry, irgendwie gab der Upload unter Anhänge verwalten hier auf epvp bei mir nen Connection Timeout o.ô

[Bot_interesierter]

Also das ist wirklich extrem merkwürdig, mit Visual Studio 2008 lies sich das Projekt kompilieren, das einzige gebliebene Problem ist die Warnung was den Konflikt mit der msvcrt Libdrary angeht.
Allerdings hat der Name der Bibliothek in deinem pragma comment nicht gestimmt, eventuell hast du ja eine andere Bibliothek gelinkt als du eigentlich wolltest, diese enthält dann natürlich nicht die Symbole die du erwartest.
Edit:
Sonst kann es eben noch sein das deine Projektkonfiguration irgendwo falsch ist, ich konnte es nicht überprüfen denn VS2010 habe ich nicht installiert.

[MrSm!th]

Hm, danke für die Anhaltspunkte. Werde mal nochmal drüberschauen.
Der Name müsste eigentlich stimmen, ich nenne die lib vor dem Verschieben immer in GHF.lib um, deshalb pragma comment (lib, "GHF.lib").
Könnte aber sein, dass ich mal vergessen hatte, zu kopieren, ich werd mal schauen.
Ansonsten probier ich es mal, den operator+ als Member von String zu deklarieren, wie gesagt, mit allen Membern gehts, nur mit den globalen operator+ Überladungen nicht.
Und ist ja auch relativ egal, ob ich dann nicht mehr die Reihenfolge bei s2 = s1 + "test" vertauschen kann.
Wobei mir gerade einfällt, in Stroustrups Buch habe ich eine Deklaration einer Überladung von operator+ in der Klasse gesehen, die zwei Argumente erwartete und wohl so zu funktionieren schien, wie die globale Überladung, wie ich sie mache. Seltsamerweise war sie als friend deklariert o.ô

Das sah ungefähr so aus:

class string
{
//...
friend string &operator+(string s1, const char *s2);
};

Das friend verwirrt mich irgendwie, die Deklaration ist doch eh in der Klasse o.ô
Und naja, da der Operator 2 Parameter hat, schätze ich mal, das würde genau so funktionieren, wie globale Version von mir und wenn man noch eine Variante mit einer anderen Reihenfolge der Parameter macht, auch in Sachen Reihenfolge beim Aufruf.
Ich kannte die Deklaration bisher nur so:

class string
{
//...
string &operator+(const char *s2);
};

Und dann müsste man den string natürlich immer zuerst schreiben, damit der Compiler es zu

s3 = s1.operator+(s2);

übersetzen kann.
Meine Intention war ja, dass die Reihenfolge egal ist, deshalb hab ich die Operatoren global überladen, damit ich eben beide Parameter bestimmen kann und nicht der erste, durch das Objekt schon geliefert wird.
Wenn ich aber Stroustrups Variante sehe, zeigt mir das irgendwie, dass es doch auch so geht oder liege ich da falsch?
Dann habe ich mir evtl. unnötig den Stress gemacht Q_Q

Naja, danke jedenfalls für die bisherige Hilfe.

[MrSm!th]

So, ich habe nun die Ursache für das Problem gefunden, nicht jedoch die Lösung:

Also, die Idee, dass nur Klassenmember exportiert werden, hat sich bestätigt.
Als ich die Überladungen von operator+ zu einer Elementfunktion machte, funktionierte es super mit dem Exportieren. Das ist insofern keine Lösung, da ich mich an die Reihenfolge GHF::String und dann was anderes halten muss.
Aber gut, wenigstens geht es schonmal.

Weiß zufällig jemand, warum VS Nicht-Elementfunktionen ums Verrecken nicht exportieren will?

Das was ich übrigens im letzten Post geschrieben habe, ging leider nicht, ich weiß nicht, warum es in Stroustrups Buch steht, wenn es sich nicht compilen lässt :'(

[MoepMeep]

Auch in Stroustrups Buch sind fehler

[Bot_interesierter]

Das ist kein Fehler von Stroustrup, sondern eher ein Interpretationsfehler seitens MrSm!ith.
Er deklariert den Operator lediglich als friend, die Definition ist nicht im Scope der Klasse, man deklariert Funktion und Operatoren als friend von Klassen damit sie zugriff auf die private und protected Member einer Klasse bekommen.
Das der Operator nicht exportiert wird muss an Visual Studio 2010 liegen, denn in VS2008 hat es geklappt, bzw deine Projekteinstellungen sind falsch.
Du kannst es ja mal mit einem expliziten extern "C" oder "C++" versuchen, aber es sollte wirklich ohne gehen, ich habe es mit mehreren Compilierversionen getestet.

[MrSm!th]

Ich weiß, was friend bedeuget, hat mich schon gewundert, was friend in der Deklaration innerhalb der Klasse zu suchen hat. Kann sein, dass ich es falsch gelesen habe und die Deklaration außerhalb der Klasse ist...
Achso, du hast es mit vs9 gemachf, ich hab mich schon gefragt, wie die Projekteinstellungen anders sein können, obwohl ich das komplette Projekt gesendet habe.
Aber eigentlich sind die weitestgehend auf default, hab nur Optimierung zu Testzwecken abgeschaltet.

edit:

ich glaubs nicht, nun hab ich das gleiche problem mit meinem D3D Menü.
lustigerweise lies sich das problem aber mit extern "C" bei deklaration und definition beheben, ich habe aber keine ahnung warum es überhaupt auftrat
danke jedenfalls für den tipp Bot

edit2:

Aber es geht nur für Funktionen innerhalb der Lib

Damit meine ich:

Die Lib exportiert Klasse A und Klasse B, wovon Klasse A Klasse B nutzt.
Im Header von Klasse B gibts ne klassenfremde Funktion.
Die kann ich in Klasse A nutzen, im Projekt, das die lib nutzt, aber nicht.