[odb-users] SQLite and std::wstring

[philly.dilly at gmail.com]

Hi (again) Boris,
Although utf8 is generally a more compact encoding, in my case I will be  
using wstring since my application deals with a lot of non latin languages  
and processing utf16 is a lot easier. I tried mapping std::wstring to TEXT  
with pragmas but then I got some compilation errors about wrong number of  
arguments or something. I'll definitely look into the mapping example!

Cheers,

Phil

On , Boris Kolpackov <boris at codesynthesis.com> wrote:
> Hi Philippe,



> Philippe Cadieux-Pelletier philly.dilly at gmail.com> writes:



> > It seems like a pretty severe shortcoming of the SQLite database binding

> > not to support std::wstring.



> I wouldn't call it "severe" since you can easily add a custom mapping

> for the std::wstring type (see the 'mapping' example).





> > Are there any plans to add support?



> Yes, we can implement built-in support if you need it.





> > I can think of two ways to add support off the top of my head:

> >

> > 1. Have some kind of setting, either at compile time or runtime, that

> > will bind SQLite's TEXT type to std::wstring and configure the SQLite

> > database to use utf16 for TEXT. This would mean that you would have to  
> pick

> > either utf8 or utf16, but at least you'd have the option of supporting

> > std::wstring.

> > 2. C++ 11 adds std::codecvt_utf8_utf16 to convert between utf8 and

> > utf16. It would then be possible to convert at runtime therefore being  
> able

> > to support both std::string and std::wstring



> In SQLite the database encoding (specified with 'PRAGMA encoding') and

> the encoding used in the application to bind parameters/results are

> somewhat independent. That is, if the database is UTF-8 and we pass

> UTF-16 text or if the database is UTF-16 and we pass UTF-8, then

> SQLite performs automatic conversions as required. So, in this light,

> it would be best to pass std::wstring as UTF-16 and let SQLite

> determine what to do. This will also give the user the flexibility

> to make the database either UTF-8 or UTF-16 without any changes to

> ODB or generated code.



> BTW, which database encoding are you planning to use in your case?



> Boris