Dallas Clarke wrote: > Well Scott, that's probably why I don't want to have to implement the string > library functions myself. With each different implementation, we will > probably get a different outcome and it makes more sense that GCC does it in > the standard C library. But gcc does not implement a standard C library. On Linux, that is usually[1] glibc -- a totally separate project from gcc. The glibc maintainers are very steadfast that wchar_t is 32 bits wide and anything narrower is broken and evil. Hell will freeze over before you convince them to change that, as they are noted for their strong personalities. Do you see now why asking gcc to make some sort of change is a losing battle? And not even on its technical merits, but because gcc has no control over the issue. > All I want is to be able to create one common source code and have it > compile in both Windows and Linux. Windows in now forcing me to use Unicode > since with Vista and Visual Studio 2008, several MFC class are no longer > supported in a multibyte compile, meaning I have to compile in Unicode. > Supplying the graphical and OS components with Unicode, my database server > need to store and process 16-bit Unicode. Without 16-bit strings in GCC, > this is now a nightmare and now I have to make a decision whether it is > worth porting to Linux/Solaris Portability is hard. This is the job of abstraction libraries like boost, gtk, and so on. It's not the job of the compiler. Brian [1] Though it could be uclibc, newlib, or something else.
