Re: UTF8 locale & shell encoding

From: Jon Hanna (
Date: Fri Jan 16 2004 - 08:09:31 EST

  • Next message: Philippe Verdy: "Re: UTF8 locale & shell encoding"

    > It would be good to say that this depends on the compiler tool you use, and
    > its version...

    True, I was refering here to VisualC++. The naming convention has been
    relatively stable for the last few versions IIRC.

     There's nothing less portable _on Windows_ than the "standard
    > C/C++ library", which try to mimic more or less successfully what is offered
    > on Unix/Linux and other POSIX systems...

    No values are defined for the names of locales by the C and C++ standards apart
    from "C" and "".

    It's not a good idea to code as if other values have any degree of
    cross-compiler and/or cross-platform stability unless you are explicitly coding
    to a standard which does define them (as I believe POSIX does) in addition to
    standards related to C++ itself.

    If this severly impacts on Deepak's work then he should use a converter from ICU
    or roll his own (from what Deepak has said it would appear that UTF-8 is the
    only encoding used here, so in this case that might be a good idea anyway,
    though it may not in other cases).

     The only stable APIs which are
    > cross-compiler compatible on Windows are the Win32 APIs, which is guaranteed
    > to depend only on the hosting OS version, but not also across the many
    > compilers available for this platform...

    MultiByteToWideChar is a windows function, it doesn't necessarily exist at all
    on another platform, and that will clearly affect matters here were Windows is
    not the only platform being coded for.
    mbstowcs is part of the C library - it *could* be buggy, not implemented or the
    source of some other problem but it is perfectly reasonable to expect it to be

    > So unless the developer sticks at a particular compiler and version for
    > Windows, using the standard library to perform locale-related work will
    > remain highly non-portable.

    Please show how this is so beyond the names of the locales.

     Almost all C/C++ sources for Windows then depend
    > on a particular compiler version, and there's no guarantee the same source
    > code will compiler and work identically with another compiler, even from the
    > same compiler provider.

    Please show how this is so beyond the names of the locales.

    Jon Hanna
    *Thought provoking quote goes here*

    This archive was generated by hypermail 2.1.5 : Fri Jan 16 2004 - 08:47:11 EST