Conversion from System::String^ to LPCTSTR

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have seen the following function to convert from a System::String^ to a
const wchar_t*. I would like to get a LPCTSTR and AFAIK LPCTSTR is equal to
const wchar_t*. Then it should all work right? But I only get the first
character. And when I try to do std::wstring l_s(convert(somestring)) I get
really strange characters into l_s string representation, but when I check
l_s individual characters they look ok.

const wchar_t* convert(
System::String^ s)
{
// Pin memory so GC can't move it while native function is called
pin_ptr<const wchar_t> wch = PtrToStringChars(s);

return wch;
}
 
Hi Joachim!
I would like to get a LPCTSTR and AFAIK LPCTSTR is equal to
const wchar_t*.
Click to expand...

No. LPCTSTR ist either const char* or const wchar_t* depending on
UNICODE macro.

My prefered way for cenversion is:

#include <windows.h>
#include <tchar.h>
using namespace System;
struct StringConvA
{
char *szAnsi;
StringConvA(System::String ^s)
:
szAnsi(static_cast<char*>(System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(s).ToPointer()))

{}
~StringConvA()
{

System::Runtime::InteropServices::Marshal::FreeHGlobal(IntPtr(szAnsi));
}
operator LPCSTR() const
{
return szAnsi;
}
};

struct StringConvW
{
wchar_t *szUnicode;
StringConvW(System::String^ s)
:
szUnicode(static_cast<wchar_t*>(System::Runtime::InteropServices::Marshal::StringToHGlobalUni(s).ToPointer()))

{}
~StringConvW()
{

System::Runtime::InteropServices::Marshal::FreeHGlobal(IntPtr(szUnicode));
}
operator LPCWSTR() const
{
return szUnicode;
}
};

#ifdef _UNICODE
#define StringConvT StringConvW
#else
#define StringConvT StringConvA
#endif

And then use it with:
#include <string>
int _tmain()
{
String ^s = "abc";
std::string ansi = StringConvA(s);
std::wstring unicode = StringConvW(s);
}

or

#include <stdio.h>
int _tmain()
{
String ^s = "abc";
printf("%s", (LPCSTR) StringConvA(s));
wprintf(L"%s", (LPCWSTR) StringConvW(s));
_tprintf(_T("%s"), (LPCTSTR) StringConvT(s));
return 0;
}


Greetings
Jochen
 
const wchar_t* convert(
System::String^ s)
{
// Pin memory so GC can't move it while native function is called
pin_ptr<const wchar_t> wch = PtrToStringChars(s);

return wch;
}
Click to expand...

Complete misuse of pin_ptr here. You must never use a pin_ptr as a return
value.

OTOH, this will work, because the wstring constructor is called while the
string is still pinned:

std::wstring convert(System::String^ const s)
{
return std::wstring(pin_ptr<const wchar_t>(PtrToStringChars(s)));
}
 
Thank you Ben,

However, that still doesn't solve my problem (and by the way I get
compilation error with it:

error C3834: illegal explicit cast to a pinning pointer; use a pinned local
variable instead f:\Development\Source\Test\MCPP\MCPP\MCPPImpl.cpp 54)

Regards,
Joachim
 
Joachim said:
Thank you Ben,

However, that still doesn't solve my problem (and by the way I get
compilation error with it:

error C3834: illegal explicit cast to a pinning pointer; use a pinned
local
variable instead f:\Development\Source\Test\MCPP\MCPP\MCPPImpl.cpp 54)
Click to expand...

ok, yeah, pin_ptr needs an explicit local, so split the one-liner:

std::wstring convert(System::String^ const s)
{
pin_ptr<const wchar_t> wch = PtrToStringChars(s);
return std::wstring(wch);
}
 
Joachim said:
Ben,

Yes that did compile, but it didn't solve the problem

Regards,
Joachim
Click to expand...

How about:

std::basic_string<TCHAR> convert(System::String^ const s)
{
pin_ptr<const wchar_t> wch = PtrToStringChars(s);
#if _UNICODE
return std::wstring(wch);
#else
int needed = wcstombs(nullptr, wch, 0) + 1;
char* pch = alloca(needed);
wcstombs(pch, wch, needed);
// optional, unpin early with wch = nullptr;
return std::string(pch);
#endif
}
 
No, it is unicode.

Ben Voigt said:
How about:

std::basic_string<TCHAR> convert(System::String^ const s)
{
pin_ptr<const wchar_t> wch = PtrToStringChars(s);
#if _UNICODE
return std::wstring(wch);
#else
int needed = wcstombs(nullptr, wch, 0) + 1;
char* pch = alloca(needed);
wcstombs(pch, wch, needed);
// optional, unpin early with wch = nullptr;
return std::string(pch);
#endif
}
Click to expand...
 
The (3rd party) function which I am passing the LPCTSTR on to takes and
LPCTSTR as argument and is working in a native C++/ATL/COM environment. In
that environment it is passed as a TCHAR*. But in this Managed C++
environment, even if I directly before the call to the function specifies
TCHAR* l_s(_T("test.mpg")) it only comes out as the filename "t".
 
Joachim said:
The (3rd party) function which I am passing the LPCTSTR on to takes and
LPCTSTR as argument and is working in a native C++/ATL/COM environment. In
that environment it is passed as a TCHAR*. But in this Managed C++
environment, even if I directly before the call to the function specifies
TCHAR* l_s(_T("test.mpg")) it only comes out as the filename "t".
Click to expand...

Is the third-party function compiled as unicode? Is it compiled from source
or provided as a binary? Statically or dynamically linked?

Also, please don't refer to VC++ 2005 as Managed C++. That is specifically
the now-dead flavor of managed extension from VC++ 2003. The replacement,
which we are discussing, is C++/CLI.
 
Yes, it must be compiled as unicode since I use it in the working native c++
version from a unicode environment.
It is provided as a binary dll and is linked statically.
 
Joachim said:
Yes, it must be compiled as unicode since I use it in the working native
c++
version from a unicode environment.
Click to expand...

Does the header file declare both Unicode and ANSI versions, like windows.h
does?

e.g. CreateFile is a #define for either CreateFileA or CreateFileW

A DLL function never accepts a TCHAR, it either accepts char or wchar_t.
With a little #define magic (or inline forwarder functions), you can make
functions that appear to accept TCHAR, but actually use different functions
inside the DLL for unicode vs ansi.
It is provided as a binary dll and is linked statically.
Click to expand...

I'll assume you mean it's dynamically linked as a load-time import.
 
The function takes an LPCTSTR as argument. I then assume that they make
themselves independent of if it is unicode or not.
A DLL function never accepts a TCHAR, it either accepts char or wchar_t.
With a little #define magic (or inline forwarder functions), you can make
functions that appear to accept TCHAR, but actually use different functions
inside the DLL for unicode vs ansi.
Click to expand...

Yes, I know. Thank you.
I'll assume you mean it's dynamically linked as a load-time import.
Click to expand...

It is a dll. I link its functions with my application at link time, not at
runtime. If that is not statically can you please clarify it for me.

Thanks,
Joachim
 
Joachim said:
The function takes an LPCTSTR as argument. I then assume that they make
themselves independent of if it is unicode or not.
Click to expand...

Source code can be usable for both unicode and ansi/multibyte, but compiled
object code cannot. There is also no way for the library to test whether
your application used a particular preprocessor define (_UNICODE) while
compiling (if your language even uses the C preprocessor). Each function in
the library is designed to accept either unicode or ansi input (it might be
possible to heuristically make a determination, but that's ridiculously
inefficient compared to the accepted method). Usually there is a A or W
suffix or the function, and the header file compiled with your application
and run through the preprocessor using your environment, selects the right
one.

If the documentation says LPCTSTR, but there aren't -A and -W variants, then
the documentation is wrong.
Yes, I know. Thank you.


It is a dll. I link its functions with my application at link time, not at
runtime. If that is not statically can you please clarify it for me.
Click to expand...

That's not statically. Statically is linking with a .obj or .lib, where the
code and data segments are merged with your application by the linker to
form one executable module that you distribute. If the library is
distributed separately, as a DLL, and merged by the process loader, that's
dynamic linking. There are several forms of dynamic linking:
* load-time, the DLL is listed in your imports table, and the OS loader
merges it before your application starts execution
* delay-load, also listed in the import table, but with a special flag, and
not loaded until you try to access it
* late-bound, the DLL isn't listed in the imports table, but you make a
runtime request. This can be an explicit LoadLibrary, or implicitly via
creating a COM object that has an InProcServer. The advantage is that
failure to merge the library doesn't cause an immediate application
shutdown, but a trappable error.
 
Back
Top