This is a DLL class to be exported
class Foo
{
public:
#ifdef UNICODE
void DoSomething(std::wstring val);
#else
void DoSomething(std::string val);
#endif
};
//assume a Foo class is created already
f.DoSomething(TEXT("abc"));
creating a DLL for both unicode and non-unicode version
Author
Hi, I am just wondering how should i handle classes in a DLL that can support both unicode and non-unicode strings?? e.g in my DLL I do
then in my main client code when i use the DLL
Hence how do ensure such that in the client code, depending on the project environment settings, I would be able to call the appropriate DLL function which matches the correct unicode string? Do I have to make different version of the DLL?? e.g
mydll_unicode.dll
mydll_nonunicode.dll
or is there anyway to combine everything to a single DLL??
thanks
Windows itself works around this problem by defining two separate entry points for each function that uses text parameters. For example, kernel32.dll implements FindFirstFileA and FindFirstFileW for ANSI and Unicode versions respectively.
Then, the public headers contain a macro (FindFirstFile) that expands to the proper version depending on the text compilation setting of the app that calls the functions. For example, in an Unicode project, the macro expands to the W version.
Then, the public headers contain a macro (FindFirstFile) that expands to the proper version depending on the text compilation setting of the app that calls the functions. For example, in an Unicode project, the macro expands to the W version.
Author
thanks for the fast replies =)
thats an interesting way. but it only works for functions right?? what about classes/methods? like in my case where the method of a class take in a string, and I want it to toggle between unicode and non unicode depending on the client settings.
Do i have to create two classes then in the public header file get the appropriate class base on the unicode project settings?? e.g
P.S i omit the other things like having a interface for the DLL class etc as it would make the post too long
then in the public header file i do something like
But doing so would make the DLL return different classes which would break when the client toggle between unicode and non unicode.
thats an interesting way. but it only works for functions right?? what about classes/methods? like in my case where the method of a class take in a string, and I want it to toggle between unicode and non unicode depending on the client settings.
Do i have to create two classes then in the public header file get the appropriate class base on the unicode project settings?? e.g
P.S i omit the other things like having a interface for the DLL class etc as it would make the post too long
//the dll fileclass foo_unicode{public: void DoSomething(std::wstring val);};class foo_non_unicode{public: void DoSomething(std::string val);};then in the public header file i do something like
#ifdef UNICODEfoo_unicode GetFooClass();#elsefoo_non_unicode GetFooClass();#endifBut doing so would make the DLL return different classes which would break when the client toggle between unicode and non unicode.
The best way to avoid the problem altogether is to just offer Unicode versions. All currently supported Windows versions support Unicode. The last that didn't was Windows Millennium Edition.
If that is not an option, you could create different method versions (DoSomethingA and DoSomethingW) and then document your library so that it is the client's responsibility to call the appropriate versions.
Alternatively, you can offer "ansi build" and "unicode build" of your library. This is a common approach.
As a side note, Windows base libraries (Win32) do not have to worry about classes and their methods because their interfaces are in C, not C++.
If that is not an option, you could create different method versions (DoSomethingA and DoSomethingW) and then document your library so that it is the client's responsibility to call the appropriate versions.
Alternatively, you can offer "ansi build" and "unicode build" of your library. This is a common approach.
As a side note, Windows base libraries (Win32) do not have to worry about classes and their methods because their interfaces are in C, not C++.
Author
haha
ok thanks. I think i would just create 2 version if the DLL since I just have to change my project settings to non_unicode and compile to get the non_unicode version.
However just asking i was thinking whether would duplicating the classes work
e.g
then in the public header file
would such a method work?? Just asking, I don't intend to use this method because i think it just involve too much work maintaining 2 copies of similar classes, making it error prone... =S
ok thanks. I think i would just create 2 version if the DLL since I just have to change my project settings to non_unicode and compile to get the non_unicode version.
However just asking i was thinking whether would duplicating the classes work
e.g
//Dll.cppclass Foo_Unicode : public IFoo{public: void DoSomething(std::wstring value);};class Foo_Ansi : public IFoo{public: void DoSomething(std::string value);};//entry point functionextern "C" void CreateFooA(IFoo** foo);extern "C" void CreateFooW(IFoo** foo);then in the public header file
#ifdef UNICODE#define CreateFoo CreateFooWtypedef std::wstring TSTRING;#else#define CreateFoo CreateFooAtypedef std::string TSTRING;#endifinterface IFoo{ void DoSomething(TSTRING value);};would such a method work?? Just asking, I don't intend to use this method because i think it just involve too much work maintaining 2 copies of similar classes, making it error prone... =S
It would probably work, but then you'd have two implementations for basically the same class, which is always bad (you could change one of them but forget to change the other, for example).
Author
thanks. haha yup i don't intend to use it only, i was just thinking if such a method would work. I just intend to release a unicode and ansi version of my dll where user can just choose the appropriate one.
Thanks nik02 =)
Thanks nik02 =)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
