How to assign CString to wstring UNICODE compilation

I have a project originally compiled ANSI, it now needs to support UNICODE.
The front end is MFC and some of the backend is std C++ stl.

Currenty under ASCII compilation I have something like:

std:string val;
CString src;

val = src;

No problem.

When compile under UNICODE then have

std::wstring val
CString src

val = src;

Wont compile.

error C2679: binary '=' : no operator found which takes a right-hand operand of type 'CString' (or there is no acceptable conversion)

Can anyone help please?
Thanks.

Quote:

---

Originally Posted by PRMARJORAM

...
When compile under UNICODE then have
...

---

How do you compile "under UNICODE"?
Did you defined both UNICODE and _UNICODE?

Quote:

---

Originally Posted by VictorN

How do you compile "under UNICODE"?
Did you defined both UNICODE and _UNICODE?

---

Im using the Visual studio 2005 compiler, so just switched the setting in the general options to the unicode character set and recompiled.

Although have edited my String typedef from std::string to std::wstring

CString is #ifdef'd to be synonymous to CStringA or to CStringW depending on settings. As victor indicates, this could be the problem.

Try literally changing yoru CString to CStringW in this particular case and retry. if it solves the issue, you need to get your compile settings corrected, if the error remains, then maybe there isn't an available (automatic) conversion available. In that case, you may need to explicitely typecast every CString to stringw conversion.

I tried CStringW, made no difference.

putting a typecast in front of the 'CStringW' also generates an error
I assume you mean

std::wstring val
CStringW src

val = (std::wstring)src;

error C2679: binary '=' : no operator found which takes a right-hand operand of type 'std::basic_string<_Elem,_Traits,_Ax>' (or there is no acceptable conversion)

std::wstring val
CString src

val = src.c_str();

I guess. you meant:

Code:

---

std::wstring val
CString src

src= val .c_str();

---

And from CStringW to std::wstring:

Code:

---

std::wstring val;
CStringW src;

val = (LPCWSTR)src;

---

Quote:

---

Originally Posted by 0xC0000005

std::wstring val
CString src

val = src.c_str();

---

CString not have the c_str() method!

error C2039: 'c_str' : is not a member of 'ATL::CStringT<BaseType,StringTraits>'

Thanks seems to be working now.

In the std C++ libs now, got lots of errors where have changed to wstring.

Got to put an L in front of any string literals.

And any str function calls got to be changed to wcs version.

Cant see we will ever go back to ASCII so dont need to control all this via some preprocessor directive.

But is this all I need to do? Are there any unforseen problems?


Thanks for your help.

Strings: Unicode and Multibyte Character Set (MBCS) Support

Quote:

---

Originally Posted by VictorN

Strings: Unicode and Multibyte Character Set (MBCS) Support

---

Yes that is very helpful thanks.
This clarifies what i have to do on the MFC side of my application to support UNICODE.

I also have similar but different problems with some libraries that are pure C++ std and STL.

I mean in there you have to use L"" whereas in MFC side you use _T("")

Thanks.

You can also use the conversion macros.

Code:

---


USES_CONVERSION;
 
std::wstring val
CString src

val = T2W( src );

---

Quote:

---

Originally Posted by PRMARJORAM

Yes that is very helpful thanks.
This clarifies what i have to do on the MFC side of my application to support UNICODE.

I also have similar but different problems with some libraries that are pure C++ std and STL.

I mean in there you have to use L"" whereas in MFC side you use _T("")

Thanks.

---

This really is more of the VC and windows environment than MFC. The bottom line is that if you use _T("") around string literals, it will work for both. If you use "" or L"", you could run into trouble. Also, consider calling api's that take strings, If you call SomeWinApi( _T("xxx") ), it's going to always work. However, without the _T("") macro, you'll need to explicitly call either the SomeWinApiA (ANSI) or SomeWinApiW (UNICODE) api version.

Can you have UNICODE and ASCII in the same program?

Actually, my specific problem is only that im downloading webpages. Most are western so no problem, but now some are not. specifically have a webpage using cyrillic text.

Im displaying a subset of the text from these webpages in a CListCtrl. When its cyrillic nothing is displayed. Im assuming here recompiling it all too UNICODE and then i should see cyrillic text in my CListCtrl? Its only in this instance i really need to use unicode - when displaying text from a non-western website?

While you *can* have both ANSI and UNICODE in a single program, I'd recommened that you compile your program for all UNICODE. If you have data coming in (or going out) that's then convert the data to UNICODE immediately so it's in one format throughout your program.

The main reason for doing this is that the Windows Operating System uses UNICODE internally and any ANSI calls you make, convert the strings to UNICODE and then just call the UNICODE version of the api. So there is extra overhead while interacting with the OS if your program is primarily in ANSI.

Quote:

---

Originally Posted by Arjay

While you *can* have both ANSI and UNICODE in a single program, I'd recommened that you compile your program for all UNICODE. If you have data coming in (or going out) that's then convert the data to UNICODE immediately so it's in one format throughout your program.

The main reason for doing this is that the Windows Operating System uses UNICODE internally and any ANSI calls you make, convert the strings to UNICODE and then just call the UNICODE version of the api. So there is extra overhead while interacting with the OS if your program is primarily in ANSI.

---

Well i did not know that, thought it may have been the other way round.


Iv recompiled my program now, after about 500 edits ;-) and is working, but...
Im getting some strange comparison results.

I have a pretty low level text comparator that also does a little parsing on some of the input.
Dotted throughout the comparator is code like the following:


if( temp[pos] == 'p' || temp[pos] == 'P' ){

Is it necessary for me to prefix _T() or L on character literals too?

Also need to detect some control codes and whitespace characters so also have


while( pos < total && ( temp[pos] < 33 || temp[pos] > 126 ))


I suspect now these are causing me problems as not comparing like with like?

Can anyone clarify this issue?

Thanks for everyones help.

Quote:

---

Originally Posted by PRMARJORAM

Can you have UNICODE and ASCII in the same program?

---

What Microsoft calls "UNICODE" is simply a toggle which causes some functions to take wchar_ts rather than chars. That's all. It doesn't do a whole lot beyond that.

You can represent Unicode data in UTF-8 using chars if you want. There's nothing forcing you to use wchar_ts and wide strings if you want to work with Unicode data.

But as has been said, the OS's native encoding is UTF-16, and the same is true of the ICU library; so if you want to avoid conversions you should work with that.

Quote:

---

Originally Posted by PRMARJORAM

if( temp[pos] == 'p' || temp[pos] == 'P' ){

Is it necessary for me to prefix _T() or L on character literals too?

---

Yes.

Code:

---


if( temp[pos] == _T('p') || temp[pos] == _T('P') )
{
 
}

---

Quote:

---

Originally Posted by Arjay

Yes.

Code:

---


if( temp[pos] == _T('p') || temp[pos] == _T('P') )
{
 
}

---

---

But with the character literals you do not get compiler errors having switched to UNICODE.
Why on strings but not on character literals?

Quote:

---

Originally Posted by PRMARJORAM

But with the character literals you do not get compiler errors having switched to UNICODE.
Why on strings but not on character literals?

---

It depends how temp is defined. If defined as char[], then you won't get errors. If defined as wchar_t[], then you should. I find developers have the least amount of trouble when coding in windows if they don't use char and wchar_t and instead use the types defined in tchar.h.

For more info, see A guideline for coding with strings in Windows.

Quote:

---

Originally Posted by Arjay

It depends how temp is defined. If defined as char[], then you won't get errors. If defined as wchar_t[], then you should.

---

In this case, you're comparing two integral types so the compiler should promote each to int before the comparison, hence no warning. If it were an assignment, you should get a warning.

Quote:

---

Originally Posted by Arjay

Yes.

Code:

---


if( temp[pos] == _T('p') || temp[pos] == _T('P') )
{
 
}

---

---

For literals in the ASCII range, I don't think this is explicitly necessary.
My compiler never complains about it. And my program works as expected.

Here's the way I look at it. When I program for Windows, I wrap any string or char literals in _T() and I never have to worry about it.

Quote:

---

Originally Posted by Arjay

Here's the way I look at it. When I program for Windows, I wrap any string or char literals in _T() and I never have to worry about it.

---

temp is defined as wstring(previously string). This library which until now was comparing only ascii codes in just std C++ although used by a Visual C++ front end application.

So I doubt the character literals are causing the problem as they would be promoted, and as I understand, the ASCII encoding is the same in UNICODE, I mean they have the same numerical numbers?

It not clear to me at this point what is causing the problem. It was previously a string comparator now a wstring comparator with the input being ASCII codes but now being converted to UNICODE. I mean Im not reading in anything yet that falls outside the ASCII range.

My problem now is in actually reading in an input file using UNICODE version of everything.
I have the following code:

CString line;
// !!! Do not include newlines
while( file->ReadString( line ) ){
mSource += line;
}
Where file is CHttpFile
and mSource is wstring.

Whats happening is the input text is being cut short in this UNICODE compilation?
Any ideas whats happening here? Has been working fine.