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 (8)

  1. David Larsson says:

    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.

  2. Anson Tsao [MSFT] says:

    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 );

    }

  3. stan lippman says:

    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.

  4. stan lippman says:

    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;

    }

  5. Jonathan Pryor says:

    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…

  6. stan lippman says:

    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.