Sign in to follow this  
mvtapia

Supporting UNICODE and Multibyte

Recommended Posts

mvtapia    112
Hello people, I want to write a library that supports both types of characters and I already wrote it so it would support both but I have a problem when the function is inside a class or a cpp file. I use #ifdef UNICODE and write the code for unicode and #else for multibyte. Now if I compile the library, I get linker errors because it doesn't know what to use. If I compile unicode and my program is using unicode, then is fine. If I compile the library in multibyte and the program uses multibyte, is fine too. The problem is when I compile the library, how do I compile the library so it supports boths. I think is because when I compile the library I'm already telling what to discriminate. Any suggestions. Thanks

Share this post


Link to post
Share on other sites
Colin Jeanne    1114
Instead of having a lot of #ifdefs in your code I would do something like what the Win32 API does. Internally do everything in one character set (probably one of the Unicode character sets) and expose two functions. One function will accept input as Unicode the other will accept multibyte input. The multibyte function will simply convert the multibyte data into Unicode and then call the Unicode function.

Then you only need #ifdefs in your headers. For example, if you had a function Foo() you wanted to expose then you'd expose two functions: FooA() and FooW() (for multibyte and Unicode input respectively). Then in your header for your library you'd have code like this:


#ifdef UNICODE
#define Foo FooW
#else
#define Foo FooA
#endif

Share this post


Link to post
Share on other sites
Muhammad Haggag    1358
Quote:
Original post by Colin Jeanne
Then you only need #ifdefs in your headers. For example, if you had a function Foo() you wanted to expose then you'd expose two functions: FooA() and FooW() (for multibyte and Unicode input respectively). Then in your header for your library you'd have code like this:

*** Source Snippet Removed ***

This isn't a very good idea. It's bound to conflict with user-defined code, since it is macro based. For example, imagine you have a class with a member function called CreateWindow. The class header file doesn't include windows headers, so all's good. The implementation file, however, includes windows headers. And suddenly the implementation of MyClass::CreateWindow becomes MyClass::CreateWindowA or CreateWindowW, causing a compilation error.

Share this post


Link to post
Share on other sites
mvtapia    112
well I tried it like colin said and I works ok, I think, The functions has the same name i just uses the one it needs.. one more thing, the UNICODE especific functions have to be declared with the unicode W at the end in order to correctly complile the library. If you use a class you have to make two diferent classes ex. ClassA and ClassW and then define
#ifdef UNICODE
#define Class ClassW
#else
#define Class ClassA
#endif

I think if microsoft does it then why cant we
thanks

Share this post


Link to post
Share on other sites
darkelf2k5    286
Why not just use Unicode only and be done with it? In this age...
Ya know all the Window$ functions are Unicode already, ***A is just a fallback and slower too, since it first converts it to Unicode then passes it to the appropriate ***W function.

Share this post


Link to post
Share on other sites
Colin Jeanne    1114
Quote:
Original post by Muhammad Haggag
This isn't a very good idea. It's bound to conflict with user-defined code, since it is macro based. For example, imagine you have a class with a member function called CreateWindow. The class header file doesn't include windows headers, so all's good. The implementation file, however, includes windows headers. And suddenly the implementation of MyClass::CreateWindow becomes MyClass::CreateWindowA or CreateWindowW, causing a compilation error.

This is a problem. Would you simply do without the #ifdefs and have two exposed functions or would you require the use of one encoding?

Share this post


Link to post
Share on other sites
Horatius83    187
I've tried using nothing but wstrings for an engine I did and ran into a lot of problems with other libraries (like DevIL, and Lua) which still use 8bit chars (or at least at that time they did). It's a good idea, but you're probably going to need to write some routines to convert 8bit chars and utf-8 data to wide char data, and sometimes convert wide chars to a string of 8-bit chars which really sucks. One thing you could do is just write two versions of the function, one for strings and the other for wstrings, with the string version just converting it to a wstring and calling the "proper" function (sort of how windows does it).

Is it just me or are there a lot of people from Japan on this forum?

Share this post


Link to post
Share on other sites
mvtapia    112
Well, I tryied to do the support for both and I think is hell. I think is better to use unicode only, since you can do anything with it.
using #ifdef inside the code is really annoying and you need to define the specific A/W function you want to use in each case. And if the #define is for a class... haha... you need to make two classes...
But i also agree that you run into a lot of problems using unicode only. I think the best option for the hobby game programmer or for the programer doing games in english is to stay with MBS, easier and you don't have to put L" before every constant string.

Wierd, many people from japan.. maybe is the time of the tread.

Share this post


Link to post
Share on other sites
small_duck    294
Your problem with the linker can be solved easily: you have to compile the library twice, with mabye different names (mylib.lib, and mylibu.lib). The users of your library should then use either the one or the other depending on whether they want unicode or multibyte.

If you are using the Microsoft compiler, the #using directive can be added into a .h so that the users of your lib wouldn't even have to worry about which library to use. Some libraries out there use this mechanism (see http://www.boost.org)

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