Sign in to follow this  
littlekid

creating a DLL for both unicode and non-unicode version

Recommended Posts

littlekid    229
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
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
};


then in my main client code when i use the DLL
//assume a Foo class is created already
f.DoSomething(TEXT("abc"));


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

Share this post


Link to post
Share on other sites
Nik02    4348
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.

Share this post


Link to post
Share on other sites
littlekid    229
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


//the dll file
class 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 UNICODE
foo_unicode GetFooClass();
#else
foo_non_unicode GetFooClass();
#endif



But doing so would make the DLL return different classes which would break when the client toggle between unicode and non unicode.

Share this post


Link to post
Share on other sites
Nik02    4348
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++.

Share this post


Link to post
Share on other sites
littlekid    229
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

//Dll.cpp
class Foo_Unicode : public IFoo
{
public:
void DoSomething(std::wstring value);
};

class Foo_Ansi : public IFoo
{
public:
void DoSomething(std::string value);
};

//entry point function
extern "C" void CreateFooA(IFoo** foo);
extern "C" void CreateFooW(IFoo** foo);



then in the public header file


#ifdef UNICODE
#define CreateFoo CreateFooW
typedef std::wstring TSTRING;
#else
#define CreateFoo CreateFooA
typedef std::string TSTRING;
#endif

interface 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

Share this post


Link to post
Share on other sites
Nik02    4348
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).

Share this post


Link to post
Share on other sites
littlekid    229
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 =)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this