How to convert LPCTSTR into std::string?

is there any code that cover LPCTSTR into std::string?  I can not find an article that provide good tutorial about string conversion from one kind to another.
tommym121Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

evilrixSenior Software Engineer (Avast)Commented:
LPCTSTR can be wide or narrow depending on your build settings. Try this...

LPCTSTR = _T("hello");
typedef std::basic_string<TCHAR> tstring;
tstring str = lpctstr;

we're creating a new std::string type that is either narrow or wide depending on TCHAR, which is set at a project level.

Note: you'll always have to use tstring as string and wstring do not honour TCHAR as this is a Microsoft specific thing (nonsense).
0
jkrCommented:
evilrix has already pointed out the most important thing - it can be both, with in the MBCS case no conversion required. So, taking that into account as well as the 'wcstombs()' from your previous Q, you can do that like

LPCTSTR tstr = _T("The quick brown fox...");
string str;
#ifdef UNICODE // conversion only required in this case
size_t len = _tcslen(tstr) + 1;
char* buf = new char[len]; // allocate temp. buffer

wcstombs(buf,wstr.c_str(),len); // do the conversion

str = buf; // assign to 'std::string'

delete[] buf; // clean up
#else
str = tstr; // not UNICODE, just assign it
#endif

Open in new window

0
sarabandeCommented:
std::string is defined as basic_string<char>. TCHAR will be mapped to wchar_t  for new MFC and ATL projects which use MS UNICODE character set. if you don't change the character set of your project to 'Multi-byte character set', std::string would not be able to take a LPCTSTR string without conversion.

you could help yourself by using the following function:

std::string TstrToStdStr(LPCTSTR psz)
{
    std::string s;
    if (psz == NULL) return s;
    if (sizeof(TCHAR) == sizeof(wchar_t))
    {
          std::wstring ws = psz;
          int wlen = (int)ws.length();
          // get needed space
          int slen  = (int)wcstombs(NULL, &ws[0], 2*wlen);
           
          if (slen > 0) 
          {
              s.resize(slen, '\0'); 
              wcstombs(&s[0], &ws[0], slen);
          }
    }
    else
    {
          s = psz;
    }
    return s;
}

Open in new window


Sara
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CompTIA Network+

Prepare for the CompTIA Network+ exam by learning how to troubleshoot, configure, and manage both wired and wireless networks.

sarabandeCommented:
Correction: before calling wcstombs you should make sure that wlen is not 0.

Sara
0
tommym121Author Commented:
Thanks
0
evilrixSenior Software Engineer (Avast)Commented:
For anyone interested, for more info on this TCHAR nonsense, why UTF16 is such a bad idea and why Microsoft made such a complete pigs ear (English slang for mess) of all things character related I recommend the following web site, which provides a pretty good (and quite interesting)  explanation.

http://www.utf8everywhere.org/
0
sarabandeCommented:
i share the negative appraisal for the t-switch and the utf16/mbcs mess microsoft was responsible for.

however, "utf-8 everywhere" is rarely a suitable concept for many parts of the world as only a little part of existing texts  is coded by utf-8 and only 7-bit ascii text can be used/displayed without restrictions. forcing all text programming to utf-8 would be a patronizing act same as it with utf-16 for all windows texts. we only would exchange one mess by another, in my opinion.

Sara
0
evilrixSenior Software Engineer (Avast)Commented:
Except, utf8 is the only format that is portable and just works on every platform, bar windows as noted above. Linux, BSD, Mac and many others have all been using utf8 as their standard format since.... well since forever and none of this mess exists there.

If Microsoft would just add utf8 support life would be a whole lot simpler.
0
sarabandeCommented:
If Microsoft would just add utf8 support life would be a whole lot simpler.
i agree. there is little to no support when using vc compiler. the only api i know is the WideCharToMultiByte function with CP_UTF8 for target code page.

when input is ansi text you have to convert to utf16 before. so it is not really simple.

Sara
0
sarabandeCommented:
it merely repeated prior comments without adding much.
actually, i made my comment without knowledge of the comment jkr has made little time before. otherwise I would have made a reference or used the function WideCharToMultiByte which has some advantages over wcstombs when the target codepage changes.

beside of the call of wcstombs both the solutions have little in common. my code is a c++ only function which converts a LCTPSTR to a std::string. jkr's code uses macros to make the switch between char and wchar_t. it is dependent on the precompiler and on environment conditions which may be a matter of change. for example, the macro UNICODE didn't exist in former versions of vc and mfc projects but only the macro _UNICODE. it is not ready-to-use and because of the usage of precompiler directives more error-prone. also it is strange that a code that should help to "overcome" the disadvantages of the TCHAR based types and go back to c++ standard and c++ standard types, that this code uses _T macro and function _tcslen which were made by MS to "support" the T-switch feature.

I think the points are ok because of that.


Modalot, i don't mind if you want to reopen the question or make your own decision. but, i hope you do no longer let me charged with having repeated from a code which actually is not recommendable in my opinion. the differences between the solutions should be obvious.

Sara
0
evilrixSenior Software Engineer (Avast)Commented:
>> Please leave your recommendations here

Heh, we'll being pedantic, http:#39570492 is the solution in the context of the original question asker, since the question is about data types and not character encoding formats. By using this as the solution there is no need to perform any conversions - either between data types nor encoding formats.

That's not to say I object to a split for assistance but this comment is the solution and should be recognised as such. That being the case my recommendation would be as follows:


Split http:#39570492 (250 points) with one or more of the remaining comments, as you see fit.
0
evilrixSenior Software Engineer (Avast)Commented:
Actually, the real solution is to not use TCHAR at all and just use standard C++ types and UTF8, but until Microsoft stop fannying about and add proper UTF8 local support this is not possible :(

Sorry, but that point is so important I felt it needed to be made again!
0
sarabandeCommented:
is there any code that cover LPCTSTR into std::string?
http:#39570492 doesn't offer a solution how to convert to std::string but how to convert to std::wstring or to std::string depending on the project settings for the character set. that was not asked and doesn't give a help to the Asker if the UNICODE setting was active in the VC project. it definitively is not a solution for the original question.

we should avoid to discuss off-topic if possible.

Sara
0
evilrixSenior Software Engineer (Avast)Commented:
The point is there is no need to convert anything. The problem is solved by avoiding it in the first place. Also, the suggestion to convert the encoding format makes the assumption that the conversion is to and from the current locale and/or that the narrow encoding is ANSI. If that isn't the case the conversion will be incorrect. Again, avoiding the re-encoding avoids this problem in the first place.

Do you consider that off-topic?
0
sarabandeCommented:
off-topic is the TCHAR point.

conversion is needed if LPCTSTR points to wchar_t.

"avoiding the re-encoding" would not have a std::string as a result what is the requirement.

I will unsubscribe now.

Sara
0
evilrixSenior Software Engineer (Avast)Commented:
>> off-topic is the TCHAR point.

Um, given that LPCTSTR represents a Local Pointer to Const T STRing (indirectly defined as a typedef of TCHAR const * -- the clue is in the name), I am at a loss as to how that could possible be the case!

What is bordering on being off topic is the fact you feel there is a need to re-encode a wide string from an unknown encoding format to a narrow string in an ANSI encoding format that is specific to the processes local.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.