use a c++ library from c#

There is either P/Invoke that works well with calling unmanaged functions, but since you wrote 'C++', I assume 'classes' where COM Interop will suit you better. Taker a look at the article at http://www.codeproject.com/Articles/5001/NET-COM-Interoperability (".NET - COM Interoperability") and if you can use the newer .NET version, look here: http://www.codeproject.com/Tips/143694/Get-rid-of-COM-Interop-DLL-by-using-the-new-C-dy ("Get rid of COM Interop DLL by using the new C# 4 dynamic keyword")

Caveat: For either approach, you will have to turn that static library into a DLL or wrap it with one.

Great answer.  But I'm not sure I want to use COM.  They need to change the name or something.  It just seems too old for some reason.  I know that's not warranted.

I've been trying to keep things extra clean- using boost and standard c++ only.  Then you had to go and mention COM.  Not very nice.

I do like P/Invoke...  But I do have classes...  Hmmmmmm.......

BTW:

>> I've been trying to keep things extra clean- using boost and standard c++ only.
>> Then you had to go and mention COM.

*pointing-finger*

You mentioned .NET first ;o)

LOL!!  COM, here I come again...  :-)

I'm working on C++/CLI now and I saw a great example on youtube where you just create a CLR class library wrapper.  I didn't see the need to use COM classes yet...  Or is this more hidden nowadays? (no _i.h & .c file)...

Also, the example I saw passed a pointer to an int array.  Converting a C# to a c++ standard string is another story.

My plan of attack... Please correct me if/where I get a bad idea?
0-  Create the CLR Class library project since it facilitates the bridge between C# and unmanaged C++ for us.
1-  The C# stuff I can keep encoded in UTF16 since it's all Windows UI.
2-  The C# String is passed to the wrapper as-is.
3-  The wrapper converts the UTF16 C# string to c++ UTF-8 std::string (** somehow ** don't know how yet)
4-  The c++ library is pure business logic, encoded in UTF-8.
5-  do the unsafe code block to call the business logic back...

This is cool stuff.  I hope I don't hit a wall...  Thanks again.

So far, that sounds OK to me. But why not strictly sticking with UTF16 throughout the whole project? This will save you from nasty surprises when some aspects change (don't ask how much encoding 'fun' we had when brokering connections between a legacy Windows app and iOS via a C# Windows service recently)

i like the idea of dropping wstring and T_ and L"" in code.  It is not cross platform.

You can encode UTF-8 in standard C++ in a std::string too.. and if I understood correctly, most if not all the strlen functions work properly...  Also, UTF-16 byte order can change- and it's not fixed width, so it's wider than need be....

What kinds of aspects can change?  If I make it a rule that my business logic remains always in UTF-8, and that I only convert to whatever is needed on the boundaries, then all is well....  No?

Well, if I *knew* what could change, things would be way too simple :-D

No, maybe I am just too overcautious and pesimistic, but that's for a reason. I've seen it all to often that customers all of a sudden add requirements that interfere with previous assumptions and therefore try to make no assumptions at all.

And now I think I've run into the need for COM....  I thought I could use my static library from within my CLR class library... But getting linker errors now... (LNK2038).  More reading to do... <sigh>

Good luck then! *duck*

Amazing.  The CLR class library does away with the visible need for COM.  You just use your .lib as an implementation within and expose what you want to c#...  You do the conversion to the different types within this library.  I'm up and running!  :-)

Well, I said it would save you from trouble ;o)

The marshalling stuff can really be a pain in the [censsored].

Here comes my next question in the c# section...  More points ?   :-)