[odb-users] SQLite and std::wstring

Boris Kolpackov boris at codesynthesis.com
Tue Jun 12 01:47:20 EDT 2012


Hi Phil,

In the future please keep your replies CC'ed to the odb-users mailing
list as discussed in the posting guidelines:

http://www.codesynthesis.com/support/posting-guidelines.xhtml

philly.dilly at gmail.com <philly.dilly at gmail.com> writes:

> Unfortunately, to the best of my knowledge codecvt_utf8_utf16 is in  
> <codecvt> :(

Ok, I did some more digging, and it appears codecvt_utf8_utf16 is an
VC10 non-standard extension that is indeed defined in <codecvt>. The
C++11 name for this functionality is std::codecvt<char16_t, char,
std::mbstate_t> that is defined in <locale> (and is probably not
supported by VC10).

You could provide two separate implementations based on the 
ODB_COMPILER macro, which is defined when the header is compiled
by the ODB compiler. However, I don't think you need to include
the traits implementation (and thus <codecvt>) in your header
file that defines persistent classes. If you look at the 'mapping'
example, you will notice that it only include the traits.hxx file
in the generated code (using the --hxx-prologue option; see the
accompanying README file for details). 


> I was already able to to define a new binding for text16 in 
> libodb-sqlite but then I ran into the architectural issue in the compiler 
> you mentioned. Guess I'll have to wait until the next version of odb :)

Note that you still should be able to provide the std::wstring mapping
by doing UTF-16 to UTF-8 conversion yourself. Seeing that you are using
UTF-8-encoded database, this conversion will have to happen either way.
Right now you will have to do it yourself. Once we support UTF-16 image
for TEXT, SQLite will be doing the conversion. The only time the latter
approach is a clear winner is when you have a UTF-16-encoded database.

Boris



More information about the odb-users mailing list