[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