Ich habe, weil es mir zum Hals rausgehängt hat, nicht mit Listen umgehen zu können, selbst eine Liste erstellt. Diese besteht aus 5 Klassen:

CBasicNode
CHeadNode
CInternalNode
CEndNode
CList

CBasicNode ist die Basisklasse für CHeadNode, CInternalNode und CEndNode. Sie hat nur jeweils einen Zeiger zum nächsten und zum vorherigen Element. CHeadNode makiert die Anfang, CEndNode das Ende der Liste, und CInternalNode nimmt den eigentlichen Wert auf. CList verwaltet Listenkopf und Listenende (CHeadNode und CEndNode) und stellt Funktionen hinzu.

Weil ich noch so gut wie keine Erfahrung mit der STL gemacht habe und mich Template-Syntaxfehler besonders lieben, wollte ich meine ursprünglich auf einen DWORD-Wert ausgerichtete Klasse CInternalNode und CList in Templateklassen verwandeln, um in späteren Programmen diese zu verwenden (da weiss man, was man hat). Nachdem ich die entsprechende Änderungen vorgenommen habe, zeigte mir mein Compiler (MSVC++ 2008 Pro) 6-Linkerfehler an, dass Templatefunktionsdefinitionen von CList und CInternalNode fehlen würden. Dazu muss gesagt werden, dass ich die Klasse an sich in eine Headerdatei verpackt habe, die Funktionsdefinitionen aber in eine .cpp-Datei speichere.

Dann habe ich (aus Zufall und Langeweile) den Inhalt der cpp-Dateien in die Headerdateien verschoben, und plötzlich lief es. Trotzdem würde ich Deklaration und Definition gerne separat sichern - oder ist das nicht möglich?

2. Funktionen in eine DLL speichern - wie?

Eigentlich hatte ich geplant, die oben erwähnten Funktionsdefinitionen der Klassen in eine DLL zu verpacken. Dummerweise habe ich keine Ahnung vom DLL-erstellen, weiss aber, dass es die Schlüsselwörter

__declspec(dllimport)
__declspec(dllexprot)

gibt. Und das war's auch schon. Weiss jemand, wie ich meine Funktionen in eine statische Bibliothek oder noch besser in eine DLL verpacke?

3. Die Bezeichnung _w64 und wofür sie steht

Beim zufälligen durchforsten der MFC ist mir die Definition des Typs UINT_PTR aufgefallen. Bei dieser steht das Schlüsselwort _w64, und da ich damit nichts anfangen konnte und auch meine Dokumentation nicht helfen konnte, dachte ich, es gäbe hier jemanden, der mir das sagen könnte.

4. Und noch mal die Liste: bestimmte Funktionen für bestimmte Typen bereitstellen.

Der Vorteil der Templates ist gleichzeitig sein Nachteil: Ich würde gerne bestimmte Funktionen bei bestimmten Typen bereitstellen, aber ich habe keine Lust, eine zweite Liste für Zeiger zu erstellen (Diese müssen anders behandelt werden als normale Variablen). Kann ich bestimmte Funktionen freischalten, wenn der Typ der Klasse statt ein char ein char* ist, oder muss ich wirklich eine neue Klasse schreiben?

Trotzdem würde ich Deklaration und Definition gerne separat sichern - oder ist das nicht möglich?

Bei Templates die Definition in eine cpp-Datei auszulagern kann leider nur der Comeau- (oder so) Compiler. Man kann aber die Definitionen in eine separate Headerdatei (oder auch Endung .impl o.ä.) auslagern und diese am Ende der eigentlichen Headerdatei mit include einbinden. So werden die Definitionen auch überall eingebunden, liegen aber wenigstens in einer separaten Datei.

3. Die Bezeichnung _w64 und wofür sie steht

Ist MSVC-spezifisch und wird da verwendet für Typen die verschiedene Größen haben, je nachdem ob du 32- oder 64Bit kompilierst.
Bei ULONG_PTR a=17; UINT b=a; könntest du z.B. eine Warnung bekommen, weil ULONG_PTR im 64Bit-Kompilat größer wäre als UINT (während im 32Bit-Kompilat alles passt).

4. Und noch mal die Liste: bestimmte Funktionen für bestimmte Typen bereitstellen.

Du könntest spezielle Funktionen außerhalb der Klasse definieren, die du aus der Klasse heraus aufrufst und die auf den jeweiligen Typ spezialisiert sind. Obwohl man das bei einer Liste eigentlich nicht brauchen sollte.

Zu (2) hab ich grad keine Lust zu antworten :p Aber such mal nach c++ make dll .

Und: Woran hapert es denn bei der Benutzung von std::list? Eigentlich ist die ja ganz simpel zu bedienen.

Der Compiler muss die Templates dort sehen, wo sie verwendet werden. Also müssen sie ins Header File, oder in ein "inline" File (ein File, welches vom Header File inkludiert wird).

Mit __declspec(dllexport) kannst du Klassen und Funktionen exportieren, und nu rate mal was du mit __declspec(dllimport) machen kannst.
Geht aber mit Templates nicht*, siehe oben.
*: geht schon, aber nur für Instanzierungen der Templates die du vorgibst. D.h. wenn du MeineListe<int> extra angibst, kannst du MeineListe<int> aus der DLL exportieren. Der der die DLL verwendet kann dann aber nur MeineListe<int> und nicht MeineListe<float> oder MeineListe<MeinSuperTyp> verwenden, es sei denn er sieht die Implementierung (siehe wieder Punkt 1)

__w64 wird verwendet, um dem Compiler mitzuteilen, dass ein Typ zwar 32 Bit gross ist, aber 64 Bit gross wäre, wenn man für 64 Bit compilieren würde.
UINT_PTR etc. sind immer so gross wie ein Zeiger, d.h. bei 32 Bit Systemen eben 32 Bit und bei 64 Bit Systemen 64 Bit.
Der Compiler gibt dir dann eine Warnung aus, wenn du z.B. einen Wert aus einer __w64 Variable in eine "reine" 32 Bit Variable kopierst. Also z.B. DWORD = UINT_PTR.

aber ich habe keine Lust, eine zweite Liste für Zeiger zu erstellen (Diese müssen anders behandelt werden als normale Variablen)

Wieso glaubst du dass du das musst/willst?
Davon abgesehen geht es natürlich. Du kannst alle gemeinsamen Funktionen in ein Basisklassen-Template packen, davon dann ein weiteres Klassen-Template ableiten, und dieses weitere Klassen-Template spezialisierst du dann.
Für "normale" Typen könnte das dann z.B. leer sein (alles schon in der Basisklasse enthalten), und die Spezialisierung für Zeiger hat dann halt ein paar Funktionen zusätzlich.

Google ist dein Freund.

Die MSDN ist dein Freund.

typedef CLink <int      > CIntLink;
typedef CLink <short int> CShortLink;
typedef CLink <long int > CLongLink;

Problem ist: ich weiss nicht mal, WIE aus meinem schnöden Code eine binäre DLL wird.

3. Danke. Das hat mich ein bisschen Wahnsinnig gemacht.

4. Ich weiss auch nicht. Vielleicht mag ich es nicht, die Werkzeuge fremder MEnschen zu nutzen, deren Code ich (noch nicht) verstehe. Solange ich jedoch nicht den Durchblick habe, werde ich schön die Finger davon lassen.

Also noch eine Klasse erstellen? Ohh, mann. Es hat zwar nur 2 Tage gedauert, das Konzept zu erlernen, anzuwenden und die Liste zu erstellen, aber ich habe schon jetzt wenig Lust, mich noch mal dranzusetzten. Vielleicht morgen oder so... schliesslich habe ich noch frei.

Problem ist: ich weiss nicht mal, WIE aus meinem schnöden Code eine binäre DLL wird.

Eine DLL erstellst du in Visual Studio, indem du einfach bei dem Projekt den gewünschten "Konfigurationstyp" angibst. Das geht bei den Eigenschaften des Projekts unter "Allgemein" - jedenfalls bei VS 2005, das ich gerade vor mir habe.

Du musst allerdings nicht nur dafür sorgen, dass deine Klassen und Funktionen aus der DLL exportiert werden (mit __declspec(dllexport)), sondern dass andere Binaries diese auch wieder importieren (mit __declspec(dllimport)). Die Klassen und Funktionen müssen also verschieden deklariert sein, je nachdem, ob sie beim Bauen der DLL selbst oder beim Bauen eines anderen Binaries gelesen werden.

Ich verwende dazu eine Lösung, die mit VS und MinGW funktioniert:

// --- MyClass.hpp

#ifdef MYDLL_EXPORTS
   #undef EXPORT_IMPORT
   #define EXPORT_IMPORT __declspec(dllexport)
#else
   #undef EXPORT_IMPORT
   #define EXPORT_IMPORT __declspec(dllimport)
#endif

class EXPORT_IMPORT MyClass {

   // ...

};

void EXPORT_IMPORT myFunction();

Jetzt muss in den Einstellungen zum Projekt, das MyDll.dll baut noch das Makro MYDLL_EXPORTS definiert sein (und in den importierenden Binaries ist es natürlich nicht definiert!). Dann klappts auch mit der DLL.

Der aus dem Westen ... schrieb:

4. Ich weiss auch nicht. Vielleicht mag ich es nicht, die Werkzeuge fremder MEnschen zu nutzen, deren Code ich (noch nicht) verstehe. Solange ich jedoch nicht den Durchblick habe, werde ich schön die Finger davon lassen.

Diese Einstellung ist für Anfänger vielleicht lobenswert. Da lernt man halt was. Allerdings führt sie auch dazu, dass du viele Dinge halt nicht verwenden kannst, die andere schon sehr gut erledigt haben. Zum Beispiel hindert es dich daran, die STL zu verwenden. Oder Boost. Oder sonst eine Library.

Vielleicht solltest du diese Haltung noch einmal überdenken?

Stefan.

Also erst mal ein neues Projekt, Anwendungstyp DLL. So war's doch, oder?

Da ich eine neue DLL ohne alte Funktionen erstellen will, muss ich dllexport verwenden, da so neue Funktionen hinzugefügt werden.

Zuerst Header erstellen, Deklarationen hinzufügen (damit man auf die Liste zugreifen kann), dann Funktionen definieren und ein Schutzmakro einbinden. Anschliessend kompilieren.

Korrigiere mich, wenn ich falsch liege. Aber was ich da hingeschrieben habe, ist sozusagen MEIN EIGENER Maschinencode. Einfache Anweisungen, das ist meine Art zu denken.

Und was die STL angeht: Ich habe vor, ein guter - ich meine ein WIRKLICH guter - Programmierer zu werden. Aber wenn ich nur den einfachen Weg gehe und mich nie mit der Interna der STL einlasse, werde ich es auch zu nichts bringen. Dazu will ich auch sagen, dass ich erst 18 bin und vor einem Jahr mit C++ angefangen habe, und ich habe die Befürchtung, dass ich den Anschluss verpassen könnte, DESHALB nehme ich den harten Weg und beschäftige mich mit Speicherverwaltung, dynamischen Arrays und komplexen Listen (denn komplexen ist die ganze Matrix schon). Und nur, wenn ich ABSOLUT nicht klarkomme (wie zum Beispiel mit selbstprogrammierten streams), greife ich auf Hilfe von Ausserhalb zu.

Also erst mal ein neues Projekt, Anwendungstyp DLL. So war's doch, oder?

Ja.

Der aus dem Westen ... schrieb:

Da ich eine neue DLL ohne alte Funktionen erstellen will, muss ich dllexport verwenden, da so neue Funktionen hinzugefügt werden.

Das verstehe ich nicht ganz. Du musst Funktionen usw. als "dllexport" deklarieren, damit sie von außerhalb der DLL verfügbar werden. Sonst kannst du die DLL ja gar nicht benutzen. War es das, was du meintest?

Der aus dem Westen ... schrieb:

Zuerst Header erstellen, Deklarationen hinzufügen (damit man auf die Liste zugreifen kann), dann Funktionen definieren und ein Schutzmakro einbinden. Anschliessend kompilieren.

Im Prinzip ja. Bitte beachte aber, dass im Falle von Templates *kein* "dllexport" verwendet werden darf. Hier sind ja die Definitionen bereits im Header vorhanden und es wird überhaupt kein Code für die DLL erzeugt.

Der aus dem Westen ... schrieb:

Und was die STL angeht: Ich habe vor, ein guter - ich meine ein WIRKLICH guter - Programmierer zu werden. Aber wenn ich nur den einfachen Weg gehe und mich nie mit der Interna der STL einlasse, werde ich es auch zu nichts bringen. Dazu will ich auch sagen, dass ich erst 18 bin und vor einem Jahr mit C++ angefangen habe, und ich habe die Befürchtung, dass ich den Anschluss verpassen könnte, DESHALB nehme ich den harten Weg und beschäftige mich mit Speicherverwaltung, dynamischen Arrays und komplexen Listen (denn komplexen ist die ganze Matrix schon). Und nur, wenn ich ABSOLUT nicht klarkomme (wie zum Beispiel mit selbstprogrammierten streams), greife ich auf Hilfe von Ausserhalb zu.

Ich möchte dich keineswegs davon abbringen, Dinge verstehen zu wollen, die du verwendest! Und Algorithmen und Datenstrukturen zu verstehen, gehört sicherlich dazu, ein guter Programmierer zu sein.

Bloß klang dein Beitrag so, als wolltest du gar nichts verwenden, das du nicht vorher verstanden hast. Und das erschien mir ein Bischen zu viel des Guten. Mehr wollte ich gar nicht sagen. Ein guter Programmierer versteht sich nämlich auch auf die Kunst, gute Dinge wieder zu verwenden. Damit er sein Ziel nicht aus den Augen verliert...

Stefan.

Das verstehe ich nicht ganz. Du musst Funktionen usw. als "dllexport" deklarieren, damit sie von außerhalb der DLL verfügbar werden. Sonst kannst du die DLL ja gar nicht benutzen. War es das, was du meintest?

Bingo! Genau das. In der Header muss die Deklaration + __declspec(dllexport) stehen. Im DLL-Projekt muss dann die Header eingebunden sein, dann kann man die Funktionen definieren, oder?

DStefan schrieb:

Im Prinzip ja. Bitte beachte aber, dass im Falle von Templates *kein* "dllexport" verwendet werden darf. Hier sind ja die Definitionen bereits im Header vorhanden und es wird überhaupt kein Code für die DLL erzeugt.

Für Templates fällt die DLL ins Wasser. Aber was ist mit statischen Bibliotheken?

DStefan schrieb:

Ich möchte dich keineswegs davon abbringen, Dinge verstehen zu wollen, die du verwendest! Und Algorithmen und Datenstrukturen zu verstehen, gehört sicherlich dazu, ein guter Programmierer zu sein.

Bloß klang dein Beitrag so, als wolltest du gar nichts verwenden, das du nicht vorher verstanden hast. Und das erschien mir ein Bischen zu viel des Guten. Mehr wollte ich gar nicht sagen. Ein guter Programmierer versteht sich nämlich auch auf die Kunst, gute Dinge wieder zu verwenden. Damit er sein Ziel nicht aus den Augen verliert...

Klar, sonst wären Vererbung, Templates und RTTI wohl verschwendet, oder?

Für Templates fällt die DLL ins Wasser. Aber was ist mit statischen Bibliotheken?

Dieselbe Antwort. DLLs enthalten fertig übersetzten Code, der unmittelbar ausgeführt wird, wenn man die jeweilige Funktion aufruft.

Im Falle von Templates (und so lange dein Compiler nicht das Keyword "export" unterstützt) wird der Code eines Templates am Ort der Verwendung/Instanziierung erzeugt. Das ist nicht ganz dasselbe wie inline aber so ähnlich.

Also kann man aus Templates keine DLLs erzeugen.

Stefan.

Aber mein Compiler unterstützt "export".

Aus deinem Post kann man erkennen, dass du Visual C++ nutzt und das unterstützt export nicht!

Also, entweder bin ich zu blöd dafür, oder mein Compiler hasst mich (was gut sein kann, da er sich immer aufhängt, wenn ich mit der rechten Maustaste klicke), um DLLs zu erstellen. Ich habe eine Klasse, die ... aber seht selbst:

// Headerdatei SimpleClassDLL.h //

#pragma once

#ifndef _SIMPLECLASSDLL_H
#define _SIMPLECLASSDLL_H

#include <iostream>
using std::cout;
using std::endl;

class CSimpleClass
{
public:
    void __declspec(dllexport) Hello();
    void __declspec(dllexport) Bye();
};

#endif

// Quellcodedatei SimpleClassDLL.cpp //

#include "SimpleClassDLL.h"

void CSimpleClass::Hello()
{
    cout<<"Hallo!"<<endl;
}

void CSimpleClass::Bye()
{
    cout<<"Auf Wiedersehen!"<<endl;
}

Hier existeren zwei Dateien: SimpleClassDLL.h, die die Deklaration der Klasse vornimmt, und SimpleClassDLL.cpp, die die beiden einzigen Funktionen der Klasse definiert. Ich kompiliere meinen Code und heraus kommt eine DLL von ungefähr 37 KB Größe. Dann will ich meine Funktionen in einem anderen Projekt unterbringen. Dazu kopiere ich den Header der Klasse und die DLL in den Projektodner und binde dann die Headerdatei ein:

// Ein anderes Projekt, Main.cpp //

#include "SimpleClassDLL.h"

int main()
{
    CSimpleClass SC;
    SC.Hello();
    SC.Bye();
    cin.get();
    return 0;
}

Hier wird die neue Klasse eingebunden, eine Instanz erstellt und die beiden Funktionen der Klasse aufgerufen. Nein, das heisst, sie SOLLEN aufgerufen werden, aber mein Linker quaselt was von wegen "nichtaufgelöstem extenem Symbol" (es heisst immer, Laufzeitfehler seien die schlimmsten Fehler, aber ich denke, Linkerfehler können einen in den Wahnsinn treiben). Kann mir jemand verraten, was ich falsch mache?

2. Du musst in dem Projekt, welches die DLL benutzt die Klasse auch wieder IMportieren - wie Du das am besten machst, ohne zwei Header für dieselbe Klasse zu erzeugen, hat DStefan schön beschrieben.

3. Beim Erstellungsprozess der DLL wird eine LIB-Datei erzeugt. Diese musst Du beim nutzenden Projekt einbinden, damit die undefined references des Linkers befriedigt werden.

Erstens:

class __declspec(dllexport) CSimpleClass{/*...*/};

Zweitens (nach der Erstellung der DLL):

class __declspec(dllimport) CSimpleClass{/*...*/};

Drittens: Die .LIB mitkopieren. Richtig?

3. Ja, und in den Projektoptionen bei "zusätzliche Linkerabhängigkeiten" eintragen, oder (ein MSVC-Konstrukt), in die Headerdatei folgendes schreiben:

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