On Fri, Nov 27, 2015 at 1:19 AM, J Decker <d3ck0r at gmail.com> wrote:
> On Fri, Nov 27, 2015 at 12:17 AM, Scott Robison <scott at casaderobison.com> > wrote: > > On Thu, Nov 26, 2015 at 11:42 PM, Igor Korot <ikorot01 at gmail.com> wrote: > > > >> Hi, Scott, > >> > >> On Fri, Nov 27, 2015 at 1:01 AM, Scott Robison <scott at casaderobison.com > > > >> wrote: > >> > On Thu, Nov 26, 2015 at 10:13 PM, Igor Korot <ikorot01 at gmail.com> > wrote: > >> >> > >> >> Hi, > >> >> Is there any way to have "sqlite3_errmsg" function return a wide char > >> > string? > >> >> Or do a conversion in a portable way? > >> >> > >> >> Thank you. > >> > > >> > The portable way would be to use the mbstowcs function from stdlib.h, > >> > though it depends on what locales are supported by the system, so > maybe > >> not > >> > as portable as you would like. > >> > >> I should've been more explicit here, sorry. > >> I'm developing in C++ and need to convert to std::wstring. > >> > >> Or maybe I can just generate my own error message based on the sqlite > >> return code? > >> > > > > Most of the comments I made previously still apply, since wstring is > just a > > basic_string using wchar_t as the character type. C++ doesn't mandate the > > character set that wchar_t encompasses or the encoding it uses for that > > character set any more than C does. I like the C++11 char16_t & char32_t > > types (when available) since they are explicitly designed for unicode. > > > > Some useful answers can be found at > > > http://stackoverflow.com/questions/2573834/c-convert-string-or-char-to-wstring-or-wchar-t > > or ... > > http://stackoverflow.com/questions/7153935/how-to-convert-utf-8-stdstring-to-utf-16-stdwstring > > don't see what converting utf8 to utf16 has to do with locale ... > or why in the last decade a useful standard function hasn't been > included in standard libraries... > Locales are the way that standards for C & C++ support conversion in a portable way. If you don't care about universal portability, or only supporting specific encodings, that makes the job somewhat easier. C11 & C++11 have actually added a fair amount of support for utf8, utf16 & even utf32, which is great, but it's still "optional" with regard to unicode. The standards bodies really seem to hate to tell implementations "you must support unicode" any more than they insist 8 bit characters are encoded as ascii or latin-1. Since a given platform might not have a need for unicode (hard as that might be to imagine) they create the infrastructure to support it. > > > ... > > > > A C++-ish way of converting a string to a wstring (assuming the > characters > > in string are all ASCII or Latin-1 and wchar_t is unicode): > > > > // horribly inefficient but illustrative > > void copy_narrow_to_wide(std::wstring& dst, const char* src) > > { > > while (*src) dst.push_back((unsigned char)(*(src++))); > > } > > > > Not that I'd necessarily recommend that, but it can work. The link above > in > > particular is useful if all you need are to convert narrow strings to > wide > > strings for internal usage (logging or such). > > > > However, I think you hit the nail on the head with your last thought > > (especially if you need to display these in potentially localized text): > > generate your own error messages based on the sqlite return code. > > > > > >> > >> Thank you. > >> > >> > > >> > There isn't really a truly portable way of converting from char to > >> wchar_t > >> > based strings, given that there is no real guarantee about what > exactly > >> > wchar_t *is*. The ISO C90 standard merely defined it as "an integral > type > >> > whose range of values can represent distinct codes for all members of > the > >> > largest extended character set specified among the supported > locales". In > >> > theory, wchar_t could be a typedef of char if a platform only > supported > >> an > >> > 8 bit character set. Unicode was being designed at the time of C > >> > standardization, but the first version of Unicode wasn't published > for a > >> > year or more after the C90 standard. Thus the wchar_t type doesn't > have > >> to > >> > be Unicode, > >> > > >> > In practical terms, I generally consider wchar_t to be a pre-2011 > method > >> of > >> > storing Unicode. Even here there are no portability guarantees. > Microsoft > >> > went all in on Unicode in the early 1990s, back when it was only a two > >> byte > >> > encoding (UCS-2), so Microsoft compilers treat wchar_t as a two byte > >> type. > >> > Unicode 2.0 extended the Unicode character set in 1996 (I think) and > >> > introduced UTF-16 as a compromise way of allowing systems that > embraced > >> > Unicode 1.0 (when it "guaranteed" a 16 bit character space) to support > >> the > >> > full space of Unicode code points from U+0000 to U+10FFFF via > surrogate > >> > pairs. Modern posix systems (as far as I know) define wchar_t to be a > 32 > >> > bit type, so you can't really convert to wchar_t in a portable way, > >> because > >> > you have to handle surrogate pairs on Windows vs simple code points in > >> > posix (though this should be handled by mbstowcs if the platform > supports > >> > wchar_t as unicode). > >> > > >> > If you only use ASCII or Latin-1 8 bit characters in your code, or are > >> > willing to treat all char objects as ASCII or Latin-1, then you can > >> convert > >> > char strings to wchar_t strings by simply zero extending each > character > >> > while copying it. Something like this (without any error checking): > >> > > >> > void copy_narrow_to_wide(wchar_t* dst, const char* src) > >> > { > >> > while (*src) *(dst++) = (unsigned char)(*(src++)); > >> > *dst = 0; > >> > } > >> > > >> > -- > >> > Scott Robison > >> > _______________________________________________ > >> > sqlite-users mailing list > >> > sqlite-users at mailinglists.sqlite.org > >> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users at mailinglists.sqlite.org > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >> > > > > > > > > -- > > Scott Robison > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Scott Robison
