3. Linker Error wegen fehlendem Unicode Support?

Linker Error wegen fehlendem Unicode Support?

  • A

    Wie in meinem anderen Thread (http://www.c-plusplus.net/forum/viewtopic.php?p=672139&highlight=#672139) zu lesen verwende ich inzwischen die CxImage Bibliothek (die auch funktioniert). Nun wollte ich meine Anwendung auf Unicode umstellen, hat auch alles funktioniert indem ich bei den Funktionsaufrufen mit Strings statt "bla" L"bla" geschrieben habe. Bei allen Funktionsaufrufen bis auf einem wo mir das L ein unresolved external symbol beschert. Hier mal zur Verdeutlichung:

    image.Save("tmp.bmp", CXIMAGE_FORMAT_BMP); /*Konvertierung des Parameters 1 von 'const char [8]'
in 'const TCHAR *' nicht möglich*/
image.Save(L"tmp.bmp", CXIMAGE_FORMAT_BMP); 
/*Nicht aufgelöstes externes Symbol '"public: bool __thiscall CxImage::Save
(unsigned short const *,unsigned long)" (?Save@CxImage@@QAE_NPBGK@Z)'*/

    Heißt das die Funktion funktioniert nicht mit Unicode und ich muss die Bibliothek neu kompilieren oder wie soll ich das deuten? Ohne die Funktion geht alles.

    0
  • R

    Was ist TCHAR? Kann es sein, dass TCHAR ein (define/typedef für ein) Typ ist, der vielleicht UCS-4 Unicode entspricht und L"" bei deinem Compiler Literale nach UCS-2 Unicode erzeugt? (Deswegen short, weil wchar_t wohl ein typedef darauf ist?)

    Ist aber nur eine Vermutung. Lies mal das Handbuch zu deinem Compiler.

    0
  • A

    TCHAR ist an zwei Stellen definiert 🙄
    Einmal in der tchar.h als wchar_t, dann nochmal in einem anderen Header-File als char falls TCHAR ndef ist. Der include von tchar.h kommt aber vor dem ifndef, also müsste das eigentlich wchar_t sein.

    //Jede Menge Kruscht min, max, PI und sowas

#ifdef WIN32
#include <windows.h>
#include <tchar.h>
#endif

#include <stdio.h>
#include <math.h>

(...)

#ifndef TCHAR
#define TCHAR char
#define _T
#endif

(...)

    Compiler ist Visual C++ 7.1 und ich glaub ich seh mich jetzt schon im falschen Forum ^^

    0
  • R

    Schau dir mal an, ob in der Library überhaupt Funktionen mit TCHAR entspr. wchar_t existieren.

    0
  • ?

    Und bitte mach wchar_t als eigenen Typ (Compileroptionen). Im Moment ist das bei dir noch ein unsigned short.

    verwende ich inzwischen die CxImage Bibliothek

    Diese Bibliothek muss entsprechende Funktionen bereitstellen, die einen Unicode-String fressen, sonst wird es nervig. Da sie anscheinend schon mal keinen entsprechenden Overload bereitstellt, könntest du Pech haben.
    In diesem Fall müsstest du jeden String nach ANSI konvertieren, was zur Laufzeit saulahm ist.

    TCHAR ist beim MSVC++ ein Typedef wahlweise auf ein char oder ein wchar_t - und für die bedingte Kompilierung gedacht. Im Zusammenhang mit dem WinAPI soll man so leicht per define eine Unicode und eine ANSI Version compilieren können.

    Ich denke aber auch, im Jahre 2005 können wir mal Programme schreiben, die einfach Unicode benutzen und kein ANSI... aufwändig ist es halt, wenn deine lib das nicht direkt unterstützen sollte. TCHAR, der tolle Mischmasch, ist nervig UND du benutzt es evtl. falsch.

    TCHAR* x = L"Hoi!"

    ist Unsinn, weil TCHAR entweder char oder wchar_t ist.
    Richtig wäre also

    TCHAR* x = _T("Hoi!");

    Überleg selber, ob du dir das antun willst...

    0
  • A

    Optimizer schrieb:

    Und bitte mach wchar_t als eigenen Typ (Compileroptionen). Im Moment ist das bei dir noch ein unsigned short.

    Jo hab ich schon gesehen, werd ich morgen machen. Hab bloß bisher noch nie wchars gebraucht.

    Also die Save-Funktion aus CxImage lautet wie folgt:

    bool CxImage::Save(const TCHAR * filename, DWORD imagetype)
{
	FILE* hFile;	//file handle to write the image

#ifdef WIN32
	if ((hFile=_tfopen(filename,_T("wb")))==NULL)  return false;	// For UNICODE support
#else
	if ((hFile=fopen(filename,"wb"))==NULL)  return false;
#endif

	bool bOK = Encode(hFile,imagetype);
	fclose(hFile);
	return bOK;
}

    Das TCHAR was da verwendet wird kommt anscheinend aus der winnt.h (sagt zumindest go to definition) und lautet wie folgt:

    #ifndef _TCHAR_DEFINED
typedef WCHAR TCHAR, *PTCHAR;
typedef WCHAR TBYTE , *PTBYTE ;
#define _TCHAR_DEFINED

    Lansgam bin ich etwas verwirrt, die Bibliothek will ich keinesfalls ändern, wenn es nicht anders geht würde ich das Ding lieber in die Tonne kloppen.

    0
  • A

    Optimizer schrieb:

    Und bitte mach wchar_t als eigenen Typ (Compileroptionen). Im Moment ist das bei dir noch ein unsigned short.

    Danke für den Tipp. Nachdem ich das umgestellt und die Lib mit Unicode-Support nochmal neu kompiliert habe, geht es jetzt. Zumindest theoretisch. Unicodezeichen macht er leider immer noch nicht, stattdessen leere Kästchen. Das hängt aber jetzt an CDC drawtext was das eigentlich können sollte.

    /Edit: Problem erledigt lag am Font.

    0
  • A

    I am building my projects with Visual Studio 2003, which likes to add
    /Zc:wchar_t as a default compiler option (at least for MFC projects). This will
    make the "wchar_t" type a built-in type (if will be mapped to the built-in
    __wchar_t type).

    I have no idea why, but linking a project that has been built with the
    /Zc:wchar_t flag against projects built without that flag -- such as the ICU
    libraries -- will introduce all kinds of "unresolved symbol" errors.

    The solution for me was to disable the /Zc:wchar_t flag for my MFC project, but
    maybe the ICU headers in forthcoming releases could simply map UChar to
    __wchar_t instead of wchar_t for MSVC...

    Kann es sein das es diese Option unter VS 6.0 nicht gibt? Weil ohne kann ich die Lib nicht kompilieren und wenn ich auf eine mit VS 7.1 erstellte linke, krieg ich zig unresolved externals.

    0
Anmelden zum Antworten