dll .h und .lib erzeugen?

xlomx

hi

ich habe vor einiger zeit eine fremde dll in eines meiner rojekte eingebunden, ihr erinnert euch? ihr habt mir sehr gut geholfen.

jetzt möchte ich solch nützliche dateien selber erzeugen. wenn ich klassenbibliothek wähle als projekt, erstellt er mir "nur" eine verwaltete klassenbiblo. das ist dann nicht genau das was ich möchte. mich stört nicht das es "verwaltet" ist sondern das es so nicht in andere programmiersprachen einbinden kann. zum beispiel pascal (delhpi). geht das mit c++/cli überhaupt?

dann hätte ich noch eine peinliche frage.
was muss ich wohin schreiben? im moment schreibe ich alles in die .h datei. das gefällt mir nicht. ich glaube auch kaum das das so gewollt ist.

so das ein paar programme auch mal nützlich für andere sein könnten, also leicht zu lesen verständlich und übersichtlich.

gruß
LoM

Jochen Kalmbach

Willst Du "unmanaged" DLLs erstellen oder "managed" (sog. Assemblies)?

Für unmanaged DLLs musst Du Win32-App auswählen und dann im Wizard auf DLL.

xlomx

mir wäre managed lieber. weil da kenne ich mich jetzt mit den sprachelementen besser aus.

Knuddlbaer

Da gibt es keine .h und lib - einfach ne Klassenbibliothek erzeugen und wenn die fertig ist mit einer anderen Anwendung einen Verweis auf die DLL legen.

(Btw.: Klassen die Du verwenden willst in anderen Programmen müssen public sein)

xlomx

@knuddelbär
dich muss ich extra begrüßen
"HI"

achso kein wunder das ich das nicht finde in den einstellungen. das problem ist dann aber das man das nur mit .net entwicklungsumgebungen benutzen kann oder?

wenn ja muss ich es doch in standart c++ schreiben

kennst du noch eine nette seite die mir sagt was ein guter programmierstil ist? also was muss ich wo hinschreiben? im bezug auf .cpp und .h dateien.

Knuddlbaer

Wenn Du ne dll in .net machst wirst Du die erst mal nur in .net Applikationen verwenden können. AFAIK gibt es irgendwelche Möglichkeiten auch aus MFC Heraus .NET Bibs zu nutzen, aber ich denke der Aufwand wäre größer als sich mit den klassischen DLLs zu beschäftigen (vorallem wenn man da etwas Übung hat).

Guter Programmiertil ist Ansichtssache.
Als grobe Regel sollten alle Deklarationen und Definitionen getrennt sein und so wenig wie möglich includiert werden. Damit sparst Du viele Problemquellen ein. Der Rest ist Erfahrung und Ansichtssache.

piXelshooter

vor allem kann die aufspaltung einzelner codefragmente (klassen zum Beispiel) in separate dateien die kompilationszeit senken, da diese wenn sie nicht geändert werden nicht neu kompiliert werden müssen.

prinzipiell schreibe ich die deklarationen in die .h, die definitionen in de .cpp. war aber auch langa daran gewöhnt, direkt alles in eine datei zu schreiben, was schnell unübersichtlich und zudem unpraktisch für diverse hilfen der ide wurde, wie z b der klassenbrowser, der dann die klassen erst mit großer verzögerung aufgenommen hat.

xlomx

ich habe jetzt die Klasse ins standart-C++ übertragen. ging leichter wie ich erst dachte.
wenn ich das jetzt kompiliere. kommt entweder eine .lib raus. oder eine .dll, jenachdem ob es eine statische oder dynamische klassen-dll ist. ich glaub ich hab da was noch nicht verstanden.
wird eine statische bilbiothek in das programm durch den counter integriert? und eine dynamische als .dll eingebunden?

gruß
lom

Jochen Kalmbach

Schau mal auf Codeproject, da gibt es genügend Beispiele wie man DLLs erstellt.
Der "trick" dabei: Du musst Deine Klasse als "__declspec(dllexport)" markieren!

xlomx

@jochen

Danke, das wars. ich hatte noch ein paar linkerprobleme. musste erst die PSDK richtig einstellen.

die headerdatei ist die selbe wie ich sie beim compilieren benutze?

Jochen Kalmbach

xlomx schrieb:

die headerdatei ist die selbe wie ich sie beim compilieren benutze?

Die Frage verstehe ich jetzt nicht ganz...

Aber als Anmerkung:
I.d.R. macht man in dem DLL-Projekt ein Define "NAMEDERDLL_EXPORTS" (o.s.ä.) und dann ein

#ifdef NAMEDERDLL_EXPORTS
#define NAMEDERDLL_API __declspec(dllexport)
#else
#define NAMEDERDLL_API __declspec(dllimport)
#endif

und dann kannst Du "NAMEDERDLL_API" einfach vor die Klasse/Methode/Daten schreiben:

class NAMEDERDLL_API TestClass {
public:
	TestClass(void);
	// TODO: add your methods here.
};

extern NAMEDERDLL int g_iDaten;

NAMEDERDLL int TestFunction(void);

Somit kannst Du dann die Header-Datei sowohl in dem DLL-Projekt verwenden, als auch mit der DLL mitliefern und in dem "Anwendungsprojekt" verwenden.

C++ Forumbot

Dieser Thread wurde von Moderator/in Jochen Kalmbach aus dem Forum C++/CLI mit .NET in das Forum WinAPI verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

xlomx

@jochen Kalmbach

du bist eine große hilfe danke. das mit den codebeispiel hab ich verstanden.
jetzt hab ich noch mehr in foren und tutorials gelesen und noch mehr verstanden. ein paar fragen sind aber noch.
Wie kann ich nur einige funktionen einer klasse exportieren? und gut wäre es auch eine andere headerdatei mit nur diesen funktionen zu haben. so das die nicht geflutet ist mit funktionen die alle importiert werden müssen.

Jochen Kalmbach

Du kannst nicht nur bestimmte Funktionen aus einer Klasse exportieren. Das geht aus Gründen der vtable nicht... sonst kann der Compiler keinen richtigen Code für den Methodenaufruf erzeugen.
Du kannst höchstens eine Klasse machen, welche Du exportierts und Du verwendest intern eine Klasse, welche Du nicht exportierst. Das ist zumindest eine "saubere" Lösung.

xlomx

Jetzt hab ich eine weile rumgeschrieben und eine menge gelesen, das ist mir alles sehr suspect.

ich habe eine klasse geschrieben, kompiliert wird sie. Ich habe darauf geachtet standart-c++ zu schreiben. damit man die überall unter windows verwenden kann.

jetzt wollte ich die testen, jetzt meckert visual studio

"Der" kann nicht als Member von "APMTEST::Form1" (verwaltet) definiert werden: Gemischte Typen werden nicht unterstützt.

Also kann ich kein objekt global anlegen, was wiederum dazu führt das ich in unterschiedlichen funktionen nicht auf das nicht angelegte objekt zugreifen kann

Jochen Kalmbach

Du machst kein Standard C++ sondern C++/CLI!
Setze den Schalter "Configuration properties|Common language runtime support" nach "No Common Language Runtime support"

xlomx

ja ich weiß,

die DLL ist in standard C++ geschrieben, da bin ich sicher. nur wollte ich die Dll in eine C++/CLI projekt verwenden, was ja eigendlich gehen sollte oder?

Jochen Kalmbach

Ja geht.
Aber Du kannst (unmanaged) Klassen in einer managed Klasse nur verwenden wenn diese als *Zeiger* definiert sind!

Also anstelle

ref class Foo
{
  CUnmanagedClass a;
};

schreibst Du:

ref class Foo
{
  CUnmanagedClass *pa;
};

(und legst die Instanz natürlich im Konstruktor oder sonstwo an; natürlich musst Du sie auch wieder irgendwo freigeben (siehe IDispisable bzw. ~ oder !)