Verzeichnis herausfinden, in welchen sich die aktuelle dll befindet.

[Frederik]

Hallo CMatt,

vielen Dank für die Antwort. Könntest Du mir noch bei diesem Fehler helfen? Und ist der HANDLE in APIENTRY der richtige Handle?

HANDLE hDllHandle;
// Dll Einstiegspunkt.
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved) {
    switch (ul_reason_for_call)	{
		case DLL_PROCESS_ATTACH:
		case DLL_THREAD_ATTACH:
		case DLL_THREAD_DETACH:
		case DLL_PROCESS_DETACH:
			break;
    }

		hDllHandle = hModule;
    return TRUE;
}

int getCurrentDllPath(char *path) {
	path=(char *)malloc(4001);

	return GetModuleFileName(hDllHandle, path, 4000);
}

Fehler:
c:\func\func.cpp(46) : error C2664: 'GetModuleFileNameA' : Konvertierung des Parameters 1 von 'void *' in 'struct HINSTANCE__ *' nicht moeglich
        Konvertierung von 'void*' in Zeiger auf nicht-'void' erfordert eine explizite Typumwandlung

[Xe]

return GetModuleFileName( (void*) hDllHandle, path, 4000);

[Frederik]

Vielen Dank Euch beiden. Es war

return GetModuleFileName((HINSTANCE__ *)hDllHandle, path, 4000);

Viele Grüße

Frederik

[Christoph]

Warum benutzt du malloc?
malloc ist C, die C++ Variante lautet new. Allerdings sollte man es nicht so verwenden wie du es machst. Eine Funktion sollte ihren Speicher immer selbst freigeben oder bereits vorher allokierten benutzen.

p.s.:
Es gibt eine sichere Methode um zu erkennen, ob jemand malloc richtig verwendet:

char* p = malloc(1);

Diese Zeile muss ohne Fehler kompilierbar sein. Das ist bei dir aber nicht der Fall, deswegen ist malloc fehl am Platz.

[-King-]

cd9000 schrieb:

malloc ist C, die C++ Variante lautet new.

Und wieder was gelernt. Bislang hätte ich malloc für gültiges C++ gehalten. Und wie lautet die C++ Variante für realloc? Ist das renew?

Jedenfalls sehe ich malloc ohne free. Außerdem hat hDllHandle den falschen Datentypen verpasst bekommen. Das muß HINSTANCE sein, oder von mir aus auch HMODULE, nicht aber HANDLE.

[Christoph]

Ok, man kann malloc auch in C++ benutzen, sollte es aber nicht tun.
Konstruktoren werden nicht aufgerufen, VTables nicht angelegt, Konsequenz bleibt nicht erhalten (soll ich diesen Speicher mit free oder mit delete freigeben?).
Nur in den allerseltensten Fällen gibt es Grund malloc zu benutzen. Dieser Fall muss aber gut begründet und kommentiert sein.
Außerdem sollte man dann <cstdlib> und nicht <stdlib.h> einbinden und std::malloc benutzen.

Zum realloc: Was spricht gegen std::vector<char>?

[-King-]

cd9000 schrieb:

Konstruktoren werden nicht aufgerufen, VTables nicht angelegt,

Das ist bei einem char besonders wichtig, stimmt.

Konsequenz bleibt nicht erhalten

Doch, wenn Du Konsistent malloc benutzt, schon.

Zum realloc: Was spricht gegen std::vector<char>?

Die STL, denn ich verwende die STL nicht und habe das auch in Zukunft nicht vor.

[Christoph]

-King- schrieb:

cd9000 schrieb:

Konstruktoren werden nicht aufgerufen, VTables nicht angelegt,

Das ist bei einem char besonders wichtig, stimmt.

Auf diese Antwort hab ich gewartet.

-King- schrieb:

Konsequenz bleibt nicht erhalten

Doch, wenn Du Konsistent malloc benutzt, schon.

Das kannst du aber nicht, weil sich damit nur eingebaute Typen und PODs allokieren lassen, keine Klassen.

-King- schrieb:

Zum realloc: Was spricht gegen std::vector<char>?

Die STL, denn ich verwende die STL nicht und habe das auch in Zukunft nicht vor.

Solange du nicht MFC benutzt...
Warum gefällt dir die STL nicht?

[WebFritzi]

cd9000 schrieb:

-King- schrieb:

Konsequenz bleibt nicht erhalten

Doch, wenn Du Konsistent malloc benutzt, schon.

Das kannst du aber nicht, weil sich damit nur eingebaute Typen und PODs allokieren lassen, keine Klassen.

Hmmm? Geht nicht sowas?

class CTest
{
private:
    int a;
public:
    CTest(){}
    void SetVal(int val){ a=val; }
};

Und dann irgendwo im Code:

CTest* test = (CTest*)malloc( sizeof(CTest) );
free( test );

[-King-]

cd9000 schrieb:

Das kannst du aber nicht, weil sich damit nur eingebaute Typen und PODs allokieren lassen, keine Klassen.

Das Argument hat irgendwie etwas für sich.

cd9000 schrieb:

Solange du nicht MFC benutzt...

Aber nicht doch!

cd9000 schrieb:

Warum gefällt dir die STL nicht?

Ich habe meine Gründe. Ich werde jetzt aber nicht JEHOVA rufen, und ich werde mich nicht steinigen lassen (jedenfalls nicht jetzt, und schon gar nicht wegen sowas). Wir können das gern per Mail diskutieren, wenn Dich das tatsächlich interessiert, aber nicht hier.

[-King-]

WebFritzi schrieb:

Hmmm? Geht nicht sowas?

Doch geht. Aber das kann man nun wirklich niemandem empfehlen. Ich bin mir sicher, daß cd9000 darauf hinaus wollte.

[Christoph]

WebFritzi schrieb:

Hmmm? Geht nicht sowas?

Wenn du mit "geht" meinst, dass es syntaktisch richtig ist (also kompiliert): Ja, siehe Kings posting.
Wenn du damit meinst, das es semantisch richtig ist (sich also richtig verhält): Nein, da weder Konstruktor noch Destruktor aufgerufen werden.

Mit placement-new kann man das aber erreichen:

#include <new>

// ...

Test* p = new (malloc(sizeof(Test))) Test;
// ...
p->~Test();
free(p);

Sehr sinnvoll ist das nicht.

[Ein ehemaliger Benutzer]

cd9000 schrieb:

#include <new>

// ...

Test* p = new (malloc(sizeof(Test))) Test;
// ...
p->~Test();
free(p);

Jedes mal, wen ich sowas sehe, weiß ich wieder, warum ich Delphi benutze. Sorry, nur mal so am Rande, bitte keinen Flamewar anfangen.