托管cstring^ 转换为 std::string

http://www.cppblog.com/BeyondCN/archive/2009/07/02/66145.html

System::String -> std::string

A reader asks,

 

Sender: Erik Brendengen

 

Is there an easy way to convert from String^ to std::string?

             Does String ^s = std::string( “bla”).c_str(); work the other way?

 

This is a FAQ, one that I myself bumped into when I had to pass a System::String retrieved from System::Windows::Forms::TextBox to a native program that expected a std::string.

 

There are generally two conversion strategies, depending on which side of the managed/native fence you wish to do the conversion work. Here are two methods making use of the PtrToStringChars( String^ ) utility from the vcclr.h header file that is part of Visual C++. Note that these are written in the new C++/CLI syntax – and that these are adapted from an internal FAQ ...

 

#include <stdlib.h>

#include <vcclr.h>

#include <string>

using namespace System;

bool To_CharStar( String^ source, char*& target )

{

    pin_ptr<const wchar_t> wch = PtrToStringChars( source );

    int len = (( source->Length+1) * 2);

    target = new char[ len ];

    return wcstombs( target, wch, len ) != -1;

}

bool To_string( String^ source, string &target )

{

    pin_ptr<const wchar_t> wch = PtrToStringChars( source );

    int len = (( source->Length+1) * 2);

    char *ch = new char[ len ];

    bool result = wcstombs( ch, wch, len ) != -1;

    target = ch;

    delete ch;

    return result;

}

 

As to the second question, does String^ s = ns.c_str() work? Yes.

Published Wednesday, June 02, 2004 2:56 PM by slippman

Comments

 

David Larsson said:

Are there any plans to, ahem, extend std::string to include constructors and extraction methods for String^, like ATL::CString currently has? 
As a sidenote, this is not the first time I find myself wanting one or two features from CString in std::string, to make the decision for which of the two classes to use for a native Windows C++ application a bit easier... 
Either way, I'm really looking forward to the new C++/CLI. Actually, the /clr switch works amazingly well even today.

June 3, 2004 10:27 AM

 

Anson Tsao [MSFT] said:

In Whidbey we'll be supplying much more direct approach to do this type of marshalling via a library. 

void F( String^ s ) 
{ 
string s1 = marshal_to<string>( s ); 
String^ s2 = marshal_to<String^>( s1 ); 
} 

If you already have a char*, and want to get a System::String from it, all you have to do is this: 

void F( const char* s ) 
{ 
String^ s1 = gcnew String( s ); 
}

June 4, 2004 3:01 PM

 

stan lippman said:

as david larsson's ahem indicates, extending the standard ISO-C++ string independent of a standard's body is, i think, unlikely at this point. however, as anson's mail indicates, there is lots of thought being given on how to help users interoperate between the native and managed platforms, and david's request for support in this is not at all unreasonable.

June 17, 2004 9:26 AM

 

stan lippman said:

Yves Dolce -- the conscience of the blogs -- rightly pointed out that they two conversion samples needlessly prolong the pinning of the internal System::Char array of the String, and has proposed the following preferred alternatives, 

bool To_CharStar( String^ source, char*& target ) 

{ 

int len = (( source->Length+1) * 2); 

target = new char[ len ]; 

pin_ptr<const wchar_t> wch = PtrToStringChars( source ); 

return wcstombs( target, wch, len ) != -1; 

} 



bool To_string( String^ source, string &target ) 

{ 

int len = (( source->Length+1) * 2); 

char *ch = new char[ len ]; 

bool result ; 

{ 

pin_ptr<const wchar_t> wch = PtrToStringChars( source ); 

result = wcstombs( ch, wch, len ) != -1; 

} 

target = ch; 

delete ch; 

return result; 

} 

June 17, 2004 12:16 PM

 

Jonathan Pryor said:

In To_string(), shouldn't 

delete ch; 

actually be 

delete[] ch; 

Since you're allocating an array, you really should use the array deletion expression...

July 2, 2004 5:00 AM

 

stan lippman said:

you are correct. it is a bad habit for an old dog who was programming with the language before this was added, and of course in current implementations, its absence is actually both non-fatal and possibly more efficient.

July 7, 2004 11:39 AM

Anonymous comments are disabled