GetObject() unter Visual Studio

Mahlzeit.
Ich hab ein Problem mit Visual Studio 2008 SP1.
Mir wird plötzlich eine Funktion einer Klasse von Visual Studio nicht mehr richtig kompiliert. Das ist nicht mein Code, aber der wurde bereits erfolgreich mit VS2008 kompiliert, von daher verstehe ich es nicht.
Der Compiler beschwert sich im Prinzip, dass GetObjectW() kein Mitglied von asIGenericObject ist. Es gibt aber in der Klasse eine Funktion mit dem Namen GetObject. Diese wird auch so aufgerufen.
Ich weiss im Prinzip woran es liegt, das liegt an diesem tollen Unicode-Automatismus und diesen ..A() und ..W() funktionen. Nur kann man das irgendwie abstellen oder gibts andere Lösungen ausser #define GetObjectW GetObject?
Grazie.
rya.

audacia

Du kannst die Headerdatei manipulieren. Für den Fall, daß du im C++/CLI-Modus kompilierst ( #ifdef _M_CEE ), wird dort anstelle des Makros eine Inline-Funktion definiert; du könntest die Anweisung abändern zu #if defined(_M_CEE) || defined(MY_PROJECT_USES_THE_GetObject_IDENTIFIER) .

Alternativen wären:
- Kompiliere das Modul, in dem die entsprechende Funktion definiert wird, ebenfalls mit #include <windows.h> , oder füge die konditionelle Definition von GetObject über GetObjectA/W an.
- Erstelle manuell einen Linker-Alias oder einen entsprechenden Thunk. Diesen Ansatz verfolgt beispielsweise CodeGear in der VCL des C++Builder, wo auch hin und wieder eine Memberfunktion GetObject heißt.

Danke für die Tipps, aber es hat nix geholfen.
Im Rahmen eines neuen Features habe ich die betreffenden Dateien in externe Projekte (ebenfalls DLL) ausgelagert und da kompilieren Sie ohne den "define-hack". Und auch ohne <windows.h> einzubinden.
CLI verwende ich nicht.. (das ist managed code, also .net oder?)
Ich versteh das nicht ehrlich gesagt :(.
rya.

Martin Richter

Kannst Du mal etwas Code zeigen.
Mir scheint es, dass Du dennoch irgendwie Managed Code verwendest.

Hi Martin.
Also der Code ist ansich nicht von mir, aber es ist ne Deklaration in reinem C++. Es handelt sich um AngelScript (http://www.angelcode.com/angelscript) und dort dessen Addons für den ScriptString. Dort wird ein Zeiger auf asIGeneric erzeugt und GetObject() aufgerufen.

// http://angelscript.svn.sourceforge.net/viewvc/angelscript/trunk/sdk/add_on/scriptstring/scriptstring.cpp?view=markup
static void StringAddRef_Generic(asIScriptGeneric *gen)
{
  CScriptString *thisPointer = (CScriptString*)gen->GetObject();
  thisPointer->AddRef();
}

// http://angelscript.svn.sourceforge.net/viewvc/angelscript/trunk/sdk/angelscript/include/angelscript.h?view=markup , Zeile 667
class asIScriptGeneric
{
//[..]
 virtual void   *GetObject() = 0;
 virtual int     GetObjectTypeId() = 0;
// [..]

In meinem Projekt wurde die Addons aus dem AngelScript-Projekt nur eingefügt und leicht bearbeitet, sprich die STL-includes rausgenommen und der stdafx.h eingebunden. Mehr nicht. Transportiere ich die so veränderten Header in ein anderes Projekt, allerdings mit der selben stdafx.h, dann kompilieren diese anstandslos.
Wer masochistisch veranlagt ist, kann das Problem anhand dieses Downloads ansehen: http://code.google.com/p/angelwing/downloads/list.
Einfach mal die #defines am Anfang der scriptstring.h entfernen. Der Download hat noch den alten Stand. Auf meinem Rechner wurde das wie gesagt bereits ausgelagert und als Plugin realisiert (was nicht an dem Fehler liegt, sondern am Design *gg*). Der Code kompiliert auch mit gcc (Windows und Linux) etc anstandslos.. daher kann kein .net drin sein.
Mich interessiert trotzdem, woher das kommt.
Danke für die Hilfe.

Martin Richter

Dann musst Du einen #undef GetObject einbauen

In etwas so:

// Nach #include <windows.h>
#undef GetObject

// Und irgendwo in Deine header den folgenden Code
inline int GetObject(HGDIOBJ hgdiobj, int cbBuffer, LPVOID lpvObject)
{
#ifdef _UNICODE
    return GetObjectW(hgdiobj, cbBuffer, lpvObject);
#else
    return GetObjectA(hgdiobj, cbBuffer, lpvObject);
#endif
}

Ja, sowas hab ich ja eingebaut und damit lies es sich auch lösen.
Aber wie bereits gesagt, die <windows.h> hab ich gar nicht im Uberheader inkludiert, da der Code in reinem C++ geschrieben ist. Nur in der dll.cpp hab ich das inkludiert, damit die DllMain passt. Problem besteht aber auch fort, wenn ich das entferne :-). Alles schon probiert hehe.
Aber ist egal, aktuell besteht das Problem ja nicht mehr.
rya.