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.

Comments

• Anonymous
  June 03, 2004
  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.

• Anonymous
  June 04, 2004
  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 );
  }

• Anonymous
  June 17, 2004
  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.

• Anonymous
  June 17, 2004
  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;
  
  }
  
  

• Anonymous
  July 01, 2004
  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...

• Anonymous
  July 07, 2004
  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.

• Anonymous
  January 21, 2009
  PingBack from http://www.keyongtech.com/2327213-managed-c/3

• Anonymous
  January 21, 2009
  PingBack from http://www.keyongtech.com/737353-i-am-a-fresh-visual