Problem with UNICODE: CStringA and CString

CStoll

Dann mußt du dem Präprozessor klarmachen, daß für diese Bibliothek andere Regeln gelten, indem du in diesem Header die nötigen #defines für die ANSI-Version rekonstruierst:

#ifdef UNICODE
#undef CString
#define CString CStringA
#endif

#include "MyAnsiLib.h"

#ifdef UNICODE
#undef CString
#define CString CStringW
#endif

Das wäre echt logisch wenn das funktionieren würde.

Tut es aber leider nicht. Habe trotz des CString redefines beim Einbinden der Header Datei der Bibliothek weiterhin den gleichen Compilierfehler.

Er überprüft wohl beim compilieren auf die "CString" Signatur, unabhängig ob der Preprocessor das durch CStringW oder CStringA ersetzt?

(Das würde erklären warum er weiterhin nur akzeptiert, dass ich die Funktion mit einem CStringW aufrufe, mit der diese dann nix anfangen kann. Da innerhalb meines Programmes ja CString CStringW entspricht.)

Martin Richter

CStringW wstring = L"1234";
libraryObject.setSomeString(CStringA(wstring));

Nein, ich kann die Funktion nicht mit CStringA aufrufen.

cannot convert parameter 1 from 'ATL::CStringT<BaseType,StringTraits>' to 'CString'
        with
        [
            BaseType=char,
            StringTraits=StrTraitMFC<char>
        ]

Er verlangt dass ich einen CStringW übergebe, da die Signatur der Funktion setSomeString(CString) ist, und innerhalb meines Programmes UNICODE definiert ist.

CStoll

Da bleibt dir wohl nichts anderes übrig, als den Bibliotheksheader an deine Bedürfnisse anzupassen (sprich: alle Vorkommen von CString durch CStringA ersetzen) und diesen Ersatzheader einzubinden. Oder - wenn verfügbar - du compilierst die Bibliothek nochmal neu im UNICODE-Modus.

(die Probleme mit UNICODE sind schon alleine schlimm genug - durch die Vermischung von ANSI und UNICODE machst du alles nur noch schlimmer)

OK, danke für die Antworten.

Ist wohl dann am einfachsten einen Wrapper für die Bibliothek zu schreiben, auch wenn ich das eigentlich vermeiden wollte.

Die Bibliothek komplett in UNICODE zu compilieren ist theoretisch auch möglich, aber die hatt schon wieder so viele Abhängigkeiten, dass ich da eigentlich gar nicht drann will.

Falls doch noch jemand einen Trick kennt mit dem sich der Compiler zufriedenstellen lässt außer die beiden erwähnten Möglichkeiten bin ich natürlich für weitere Vorschläge dankbar.

Grüße ~fog

CStoll

Du könntest auch deine Anwendung im ANSI-Modus compilieren.

Martin Richter

Man könnte auch einfach vor dem besagtem Header include ein

#define CString CStringA
#include "AnySillyLibUsingCStringAsAgrument.h"
#undef CString

machen...

BTW: Wenn die EXE und die DLL/LIB nicht die selbe CRT und MFC verwenden, dann rennst Du sowieso in Teufels Küche...

Ja, das ist natürlich das einfachste. Das funktioniert auch problemlos. Aber es soll halt unicode unterstützt werden, also habe ich diese Wahl nicht.

Martin Richter schrieb:

Man könnte auch einfach vor dem besagtem Header include ein
#define CString CStringA
#include "AnySillyLibUsingCStringAsAgrument.h"
#undef CString
machen...

BTW: Wenn die EXE und die DLL/LIB nicht die selbe CRT und MFC verwenden, dann rennst Du sowieso in Teufels Küche...

So etwas hat CStoll schon vorgeschlagen. Das funktioniert nicht, da er beim Aufruf einer library Funktion aus dem Programm weiterhin auf CStringW besteht, also CString als Signatur der Funktion hat, nicht CStringA.

Martin Richter

Es gibt keine Signatur CString!

CString ist ein typedef auf
typedef ATL::CStringT< TCHAR, StrTraitMFC_DLL< TCHAR > > CString;

Und dieser ist damit entweder:
typedef ATL::CStringT< wchar_t, StrTraitMFC_DLL< wchar_t > > CStringW;
typedef ATL::CStringT< char, StrTraitMFC_DLL< char > > CStringA;

Punkt!

Uhmm... jup, du hast recht.

Ich habe mich durch die Compilermeldungen verwirren lassen. Irgendwie konnte ich mir nur so erklären, dass er die Funktionen die ich mit CString in der Bibliothek aufgerufen habe nicht gefunden hat, Funktionen ohne CString Parameter aber schon.

Tatsächlich lag es daran, dass in den beiden Projekten die Einstellung "treat wchar as build in type" unterschiedlich eingestellt war.

Tut mir leid, dass ich hier falsche Sachen erzählt habe, benutze zum ersten mal unicode / wchar und hab mich gleich ganz schön verrannt.