STL: how to convert wstring to string

[gerg]

How would one convert a wstring to a string?

This is what I have so far:

bool copyto(std::string& l,std::wstring& r)
{
bool ret = false;

size_t i = 0;
const size_t n = r.length()+1;
l.resize(n); // make sure we have enough
for(;i<n;++i)
{
l = r;
}
l = 0;
l.resize(n-1);

return ret;
}

which I know is pretty gruesome, but does the job.

the reason for: const size_t n = r.length()+1;
is because I want to make sure I have enough room to transfer the
characters.

 

[roberth+news]

| How would one convert a wstring to a string?

I'm not sure whether or not this is portable, but on many systems one
could, given the wstring containing only characters in the range of
char, do an elementwise copy.

| This is what I have so far:
|
| bool copyto(std::string& l,std::wstring& r)
| {
| bool ret = false;
|
| size_t i = 0;
| const size_t n = r.length()+1;

this is one too many.

| l.resize(n); // make sure we have enough

we don't need the extra byte.

| for(;i<n;++i)
| {
| l = r;
| }
| l = 0;

strings are not zero terminated.

| l.resize(n-1);

And here we are removing the last character again.

| return ret;
| }
|
| which I know is pretty gruesome, but does the job.

It would be somewhat simpler if you would not pretend you needed the
extra zero. If that is needed, the string class would take care of the
job.

| the reason for: const size_t n = r.length()+1;
| is because I want to make sure I have enough room to transfer the
| characters.

No, it's for making sure you have enough room to transfer an extra
character too. Anyhow, you are reinventing the weel. The constructor
and some member functions of string takes iterators of different types
as parameters. The code below demonstrates some.

wstring ws = L"Hello";
string s(ws.begin(), ws.end());
s.assign(ws.begin(), ws.end());

 

[gerg]

wstring ws = L"Hello";

sweet, thanks

-greg

 

[gerg]

example doesn't compile. i didn't realize that string wasn't null
terminated! OK thanks.

 

[Mateusz Loskot]

wstring ws = L"Hello";
string s(ws.begin(), ws.end());
s.assign(ws.begin(), ws.end());

Generally, It works but it doesn't take codepage/charset into
consideration.

Cheers

 

[roberth+news]

| (e-mail address removed) wrote:
| >
| > wstring ws = L"Hello";
| > string s(ws.begin(), ws.end());
| > s.assign(ws.begin(), ws.end());
|
| Generally, It works but it doesn't take codepage/charset into
| consideration.

<quote>
I'm not sure whether or not this is portable, but on many systems one
could, given the wstring containing only characters in the range of
char, do an elementwise copy.
</quote>

That's what my disclaimer is all about.

§ 2.2.3 guarantees that char and wchar_t has some characters in common.
(A-Z, a-z, some whitespace characters, some punctuation characters, and
some control characters.) The specific values are
implementation-defined. That means that your compiler must document
whether or not this should work.

 

[Michiel.Salters]

| (e-mail address removed) wrote:
| >
| > wstring ws = L"Hello";
| > string s(ws.begin(), ws.end());
| > s.assign(ws.begin(), ws.end());
|
| Generally, It works but it doesn't take codepage/charset into
| consideration.

<quote>
I'm not sure whether or not this is portable, but on many systems one
could, given the wstring containing only characters in the range of
char, do an elementwise copy.
</quote>

That's what my disclaimer is all about.

§ 2.2.3 guarantees that char and wchar_t has some characters in common.
(A-Z, a-z, some whitespace characters, some punctuation characters, and
some control characters.) The specific values are
implementation-defined. That means that your compiler must document
whether or not this should work.

Well, your original disclaimer didn't exacly mention that even if
wchar_t can hold a superset of char it doesn't imply that the same
character
must have the same value. Furthermore, even your second post isn't
complete.
The compiler doesn't have to document whether the other char values
also
match wchar_t values. This is rarely the case. On systems where wchar_t
is Unicode and char is ISO-8859-1, this is true. On systems where
wchar_t
is Unicode and char is NOT ISO-8859-1, it's not true. Since Europe
needs ISO-8859-15 nowadays, and Windows uses CP1252 for char, don't
count on it. Just try the euro sign (U+20AC)

HTH,
Michiel Salters