Thread: Use 'string' type in VS2010 starting from empty project

When performing cross language work, Opariti, strings become a large problem because string representations are not standardized as is the case, for example, with 32 bit integral quantities, i.e., signed integers, unsigned integers, etc. Use of the C++ std::string or std::wstring is particularly problematic. That is an entity unique to the C++ Standard Library. I don't believe .NET is aware of it in any sense.

The lowest common denominator with regard to strings are character or wchar_t null terminated arrays. With regard to .NET specifically, I believe the BSTR data type will likely take you farthest. It is defined in various Windows headers, and implemented in various Windows specific libs such as oluauto32.lib. .NET is built upon COM (Component Object Model), and that is essentially the COM string data type, and .NET recognizes it. Essentially, a BSTR is a null terminated wide character array with the length cached right at the start of the memory allocation for the string. I could give you examples of its use if you like.

Thing is I interoperate between different languages all the time, and either simple null terminated character arrays, or COM BSTRs are the way to go. But my belief is that the C++ std::string or std::wstring class will get you nowhere. The only way you would be able to make any use of that whatsoever would be through its std::wstring::c_str() member, which brings you right back around to what I told you, that is, null terminated strings are the lowest common denominator.

Here is a pretty good link about interoperating between C++ and BSTR consuming clients ...

https://social.msdn.microsoft.com/Fo...rum=vblanguage

I'm using Visual Studio 2010 Professional - old, but I have to use this one.

Don't feel bad. I still mostly use Visual Studio 2008, which works perfectly, which is more than I can say for the C++ compiler that ships with Visual Studio 2015. I've just spent the past four days trying to overcome a bug in this latter compiler, which in some cases can't satisfactorily execute operator delete [] calls, and throws all kinds of bizarre linker errors on completely valid code.

One thing I might add is that using std::wstring within your C++ dll would be perfectly fine, and likely you are comfortable with that. Where the problem comes in is the interface between the C++ dll and .NET. Of course that interface is through exported functions with their parameter lists. Incoming strings of whatever form could be converted to std::wstring within your dll for you to make use of the std::wstring members. Same thing with outgoing strings. You could convert them from std::wstring to BSTRs quite easily.

The more I think about it, I'm thinking the .NET string type must internally be a BSTR. The reason I say that is because a number of years ago I wrote an ActiveX Grid Control using all low level COM code, i.e., no ATL wrappers or anything like that, and I tested it in VB.NET, and it works fine there. The BSTR parameters I used just showed up as regular .NET strings, and the intellisense IDE recognized them as such.

If you have a std::wstring object such as this...

Code:

std::wstring s1(L"Hello, World!");

...to convert that to a BSTR its just something ike this...

Code:

BSTR strHello=SysAllocString(s1.c_str());

The main issue in using these creatures from C++ is you need to be very careful about memory leaks, as most allocated BSTRs need to be released. That article by Allen McKinney above goes into that.