[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