Thanks for your thoughts.  Your first proposal (as I understand it) creates
unnecessary steps to end up with data that Sqlite can use.  Here's an
example of the round trip flow of data in your proposal:

        User input (UTF-16)
        -> UTF16_To_UTF8()
        -> sqlite_function()
        -> MultiByteToWideChar()
        -> Win32FunctionW()
        -> WideCharToMultiByte()
        -> Data Sqlite can use

Why the conversion back to wide characters within SQLite?  In my proposal,
the flow is as follows:

        User input (UTF-16)
        -> UTF16_To_UTF8()
        -> sqlite_function()
        -> Win32FunctionA()
        -> Data Sqlite can use

Your second proposal is to prevent me from using UNICODE within my parent
application?  Can't do that.  Naïve programmers will already know something
needs to be done (convert UTF-16 to UTF-8) in order to use the sqlite
functions in the first place.  Their app won't compile if they try to feed
in wide strings.

Any follow-up thoughts?

Rob

-----Original Message-----
From: Arthur Hsu [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 21, 2003 2:24 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] Win32 coders: change os.c?
Importance: Low


Not quite.  IMHO, it's better that os.c catches this UNICODE macro, and then

uses MultiByteToWideChar and WideCharToMultiByte inside.  The other way is

to use an assert(FALSE) to prevent compilation using UNICODE, then the naive

programmers like me will know something needs to be taken care of.



-Arthur



----- Original Message ----- 

I think you can see where I'm going with this.  To fix the problem, I

propose that for the functions listed above, os.c should always call the

'real' function name, and it should be the one ending with an 'A'.  As it

stands, the os.c has no ability to deal with wide characters, so there is no

reason it should ever call the wide version of these Win32 functions.



Thoughts?



Regards,

Rob Fowler







---------------------------------------------------------------------

To unsubscribe, e-mail: [EMAIL PROTECTED]

For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to