Sign in to follow this  

Mixing languages in .NET

This topic is 4132 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A while ago i made a post here complaining about the inability to write a generic vector class in C#. In summary, C# only allows you to use functionality of type parameters that is guaranteed to exist, but there is no common interface implemented by artithmetic type that specifies them as all having arithmetic operators defined. So the question is: cant i write a templated vector class in managed C++, compile that into a dll, and call that from my C# program? How would i pass a type parameter from C# to C++ anyway, given that they use different systems for such? Is this even possible, as C++ resolves templates at compile time and DLL's are compiled?

Share this post


Link to post
Share on other sites
Writing a template vector class in managed C++ will do you no good, because you can't put templates classes into DLLs and have things work. You can only put explicit instantiations of template classes into the DLL. This is true no matter what language is using the template class.

Share this post


Link to post
Share on other sites
Managed C++ compiles to CLR in managed assemblies, just like C#, or VB.NET, or any other .NET language. This means that anything you can do in one language, you SHOULD be able to do in another (unless that language is missing the necessary affordances like keywords).

This also means that features in C++ that are not available in the CLR, are not available in Managed C++; you'd have to call out to unsafe or native blocks to make that happen.

The C#-style templates are part of the CLR specification, so such a template defined in managed C++ would work. However, if you try to add the operators, you may end up with compile errors when targeting the CLR -- try it yourself and see!

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Writing a template vector class in managed C++ will do you no good, because you can't put templates classes into DLLs and have things work. You can only put explicit instantiations of template classes into the DLL. This is true no matter what language is using the template class.


ok... so i could write a templated vector class, instantiate all typical vectors, like FloatVector, DoubleVector, and then use those?

not really statisfactory, but not as annoying as having to write the very same code twice.

Share this post


Link to post
Share on other sites
While not the most elegant solution, creating one or more buffer classes that wrap up raw ints and what not would work reasonably well. Define an interface that defines an Arithmatic type, and have your custom types all target it. Then, create a wrapper class that also targets it, but is intended for the native types with a couple of appropriate casts. Then, you can do:

MathVector<MyInt> v = new MathVector<MyInt>(5, 6, 7)

Writing the various wrappers could be a little tedious, but at least you do that once and your interface to the actual vector remains consistant. IE no MathVectorInt, MathVectorFloat, et cetera.

CM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
that's one of the things that bothers me about .net a little that they're throwing interfaces at us and require you to create a pile of interfaces but yet don't offer the flexibility (and difficulty, i admit) that c++ templates have.
personally, in your case i'd just create a vector template in c++/cli and instantiate it for the types you need so it can be used from outside the c++/cli dll. you could even go as far as having a mixed mode c++/cli dll where the data for your vectors is 16 byte aligned: in case you want to taylor your vector algorithms to SSE you just need to alter code in this one dll not affecting the rest of your code. i think math libraries are quite the right place for mixed mode c++/cli.
i developed the habit of having the data of the most core computational parts of the app 16 byte aligned so i can more easily jump in later and add SSE. if you haven't thought of that upfront it's very hard to change the code later.
if you decide that you won't ever use SSE you might throw this idea out the window and might even go with /clr:pure.

cheers,
simon

Share this post


Link to post
Share on other sites

This topic is 4132 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this