string conversion
-
Hi All! just wanted to ask, if i have a function which expects a LPCTSTR.. is it ok to call it as shown below func(LPCTSTR lp) { .... } 1) CString str="something"; func(str); 2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type func((LPCTSTR)str); thanks! me
-
Hi All! just wanted to ask, if i have a function which expects a LPCTSTR.. is it ok to call it as shown below func(LPCTSTR lp) { .... } 1) CString str="something"; func(str); 2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type func((LPCTSTR)str); thanks! me
ginjikun wrote:
is it ok to call it as shown below
Coding schemes aside, yes. If it wasn't, the compiler would surely complain.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
Hi All! just wanted to ask, if i have a function which expects a LPCTSTR.. is it ok to call it as shown below func(LPCTSTR lp) { .... } 1) CString str="something"; func(str); 2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type func((LPCTSTR)str); thanks! me
- one is OK. 2) is bad, since it will work only on UNICODE builds. it is better:
LPTSTR str = _T("something");
func(str);BTW: The
L
prefix does the magic for wide character literals, for instanceLPWSTR str = L"something"
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
Hi All! just wanted to ask, if i have a function which expects a LPCTSTR.. is it ok to call it as shown below func(LPCTSTR lp) { .... } 1) CString str="something"; func(str); 2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type func((LPCTSTR)str); thanks! me
ginjikun wrote:
- CString str="something"; func(str);
ok.
ginjikun wrote:
- LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type
LPWSTR str = L"something"; LPCWSTR str = L"something";
ginjikun wrote:
func((LPCTSTR)str);
requires care. in this case if your project is unicode, it is safe.
-
ginjikun wrote:
- CString str="something"; func(str);
ok.
ginjikun wrote:
- LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type
LPWSTR str = L"something"; LPCWSTR str = L"something";
ginjikun wrote:
func((LPCTSTR)str);
requires care. in this case if your project is unicode, it is safe.
-
- one is OK. 2) is bad, since it will work only on UNICODE builds. it is better:
LPTSTR str = _T("something");
func(str);BTW: The
L
prefix does the magic for wide character literals, for instanceLPWSTR str = L"something"
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
Hi, thanks for the reply! the assignment is just a sample.. however i am more concern with how FUNC is being called. you mentioned it will work only on UNICODE. what if the project is compiled with _MBCS, will FUNC((LPCTSTR)str) still work? thanks! me
if you define
_MBCS
instead of_UNICODE
thenFUNC((LPCTSTR)str)
expectsconst char *
but you're passing instead aconst wchar_t *
. the pointer types are quite different and you're forcing the latter into the former with static cast, i.e. mistake. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
No, it is not ok. My previous statements is still correct. func((LPCTSTR)str); requires care. in this case if your project is unicode, it is safe.
ginjikun wrote:
what if the project is compile with _MBCS? will it still be ok?
with the project settings, whenever the LPCTSTR is defined as LPCWSTR it is safe, as the str is of type LPWSTR. AFAIK, MBCS is not wide character, so passing wide character to function taking MBCS is not safe. mostly, Wide character and single character is used without any precautions simply using generic text mapping functions, but MBCS requires additional handling like (You must keep track of which bytes are lead bytes).
-
Hi All! just wanted to ask, if i have a function which expects a LPCTSTR.. is it ok to call it as shown below func(LPCTSTR lp) { .... } 1) CString str="something"; func(str); 2) LPWSTR str="something"; <-- just a sample, not sure how to set a LPWSTR type func((LPCTSTR)str); thanks! me
-
if you define
_MBCS
instead of_UNICODE
thenFUNC((LPCTSTR)str)
expectsconst char *
but you're passing instead aconst wchar_t *
. the pointer types are quite different and you're forcing the latter into the former with static cast, i.e. mistake. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
Hi, thanks again. since it is an mfc project i just cast it to CString instead. func((CString)LPWSTR) i think this should be ok... ??? me
ginjikun wrote:
i think this should be ok... ???
That works thanks to temporary
CString
object's constructor (it perforforms the conversion). :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke