ich möchte in einer dll herausfinden in welchem Verzeichnis sie sich gerade befindet. Hat jemand ne Ahnung wie das geht?

Viele Grüße

Frederik

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

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

Viele Grüße

Frederik

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.

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.

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

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.

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?

-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 );

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.

Hmmm? Geht nicht sowas?

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

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.

#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.