(Re-adding codekiddy and Fan to To:)
On Tue, Feb 17, 2015 at 11:18 AM, Arnavion <arnavion gmail com> wrote:
> Compiling as either MultiByte or Unicode should not make a difference.
> That setting only affects the use of unannotated Windows API, but
> glib/gtk should already be using the W forms of those API (with an
> intermediate utf8<->utf16 step). MultiByte is probably there in the
> project files because it's the default for new projects. Changing it
> should make no difference.
>
> If you find something that breaks because it uses the unannotated form
> of a Windows API on a utf8 string expecting to get the A version, this
> would break when you changed it to Unicode since it would now try to
> run the W version on a utf8 string. If you find such a case, I think
> you should file a bug for it.
>
> (That said, I don't see the point of changing this. In the best case,
> you would find a bug where an A version of some API is being called
> with a utf8 string instead of W version with utf8<->utf16 conversion
> step. In the worst case, you'll achieve nothing.)
>
> -Arnav
>
> On Tue, Feb 17, 2015 at 11:09 AM, John Emmas <john creativepost co uk> wrote:
>> On 17/02/2015 18:36, codekiddy wrote:
>>>
>>> (even Fan's projects which I'm using) which were
>>> set to Multibyte character set are now set to *unicode character set*
>>>
>>> Can you tell what consequnces could that have?
>>> I'm starting to think it would be better to re-compile everything with
>>> Multibyte instead because I have bad problems with GTK+ on run-time, there
>>> should be reason why those projects found in official sources are all set to
>>> Multibyte??
>>>
>>
>> Hi there,
>>
>> As someone else who builds a lot of GTK related stuff with MSVC, my
>> experience has been that the most commonly used Unicode format (for GTK+
>> based projects) tends to be UTF-8. UTF-8 can only be represented easily
>> when you select the multibyte character set. Windows Unicode uses precisely
>> 2 bytes to represent each character. But UTF-8 can use anywhere between 1
>> byte and 4 bytes (in fact, I think the early implementations could use up to
>> 6 bytes!) It probably makes things a lot easier too for Glib::ustring.
>>
>> Hope that explains it.
>>
>> John
>> _______________________________________________
>> gtk-list mailing list
>> gtk-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gtk-list