Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have existing C++ lib containing many different classes working together. Some example usage should include something like passing an instance of one class to constructor/method of another class.
I am planning to provide a C# binding for these C++ classes using C++/CLI therefore I don't have to port the whole C++ code.
I can already do this in "Facade" way by creating another class which hides all the classes used in existing C++ code from the user. However, what I want is to provide the same classes with same method signatures to the user.
Is there any guideline or recommendation for this?
ps. I have looked at some of the existing opensource C# to C++ bindings projects. But they seem to used many different ways of doing this, and I don't really understand it.
A lot of this is going to depend on the factoring of your classes.
In the work that I do, I try to treat the C++ classes I model as hidden implementation details that I wrap into appropriate C++/CLI classes. For the most part, I can get away with that by having managed interfaces that are NOT particularly granular. When your implementation involves directly implementing every detail of the underlying C++ code, then you'll end up with a very "chatty" interface that will involve a fair amount of cost in managed/unmanaged transitions.
In particular, if your unmanaged C++ classes use stl, especially stl collection types, you will likely find yourself in for an unpleasant surprise when you discover that every iteration through your stl collections involves several managed/unmanaged transitions. I had an image decoder that used stl heavily and it ran like a dog because of that. The obvious fix to put #pragmas around the code that accessed stl types didn't help. What I found that did work was to hide all of that in a handle-based C interface that hid all the C++-isms behind an iron curtain. No stl exposed anywhere meant that it was allowed to exist as unmanaged code.
I think your biggest issue is going to be in how you handle collections (if you use any) as the C++ collection philosophy and the .NET collection philosophy don't match up well. I suspect that you will spend a lot of time mapping .NET collections of adapted classes to your C++ collections of classes/types.
EDIT
Here's a blog article I wrote about this issue some time ago. It uses the managed C++ dialect, not C++/CLI, but the issue is the same.
I once did a C++ binding with C# using only [DllImport] attribute. If you don'd have any of the STL issues out fried up here says, and your lib is simple enough (as a single DLL, for example), I guess it's the easiest way to bind C++ and C#.
Simple example on MSDN: http://msdn.microsoft.com/en-us/library/aa984739(VS.71).aspx
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm learning C# recently with a strong C++ background, and there is something about C# that I don't quite understand, given my understanding of and experiences with C++.
In C++, people do care a lot about uniformity, otherwise it would be impossible to write generic code using template meta-programming. In C#, however, people seem to care little about uniformity. For example, while array types have a Length property, List<T> uses Count. While IndexOf, LastIndexOf, and alike for array types are static methods, their counterparts for List<T> are not. This gives me the impression that instead of being uniform, C# is actually trying hard to be nonuniform. This doesn't make sense to me. Since C# doesn't support template meta-programming, uniformity is not that important as in C++. But still, being uniform can be beneficial in many other ways. For example, it would be easier for humans to learn and master. When things are highly uniform, you mater one, and you master it all. Please note that I'm not a C++ fanatics nor diehard. I just don't really understand.
You've got a conceptual issue here.
List<T>, and the other collection classes with it, aren't C# constructs. They are classes in the BCL. Essentially, you can use any BCL class in any .NET Language, not just C#. If you're asking why the BCL classes differ in certain ways, it's not because the designers disrespected or didn't want uniformity. It's probably for one of (at least two) reasons:
1) The BCL and FCL evolved over time. You're likely to see very significant differences in classes that were introduced before and after generics were added. One example, DataColumnCollection, is an IEnumerable (but not an IEnumerable<DataColumn>). That causes you to need to cast to perform some operations.
2) There's a subtle difference in the meaning of the method. .Length, I believe, is made to imply that there's a static number somewhere, where .Count implies that some operation might be done to get the number of items in the list.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have the source code for a C library that I need to use with my C# ASP.Net application. It sounds like the way to handle this would be to create a C++ dll wrapper and DLLImport that into my C# project. I have found this to be kind of ugly as far as when it throws an exception the entire application crashes. Is this the best way to accomplish this, or is there a safer way? I am trying to do some research on how I might be able to make a COM object with the C library, but haven't really found much there. Is it possible to make a COM object and reference it as .NET managed code?
I googled my way around this. I found this great article comparing
a C# facade using with PInvoke and a lot of marshalling
a Facade into the interop layer in C++/CLI and compiling in mixed mode for consumption by C#.
Also, this MSDN citation : C++ Interop is recommended over explicit PInvoke because it provides better type safety, is typically less tedious to implement, is more forgiving if the unmanaged API is modified, and makes performance enhancements possible that are not possible with explicit PInvoke.
Also your idea(C++ COM facade) seems legit as preached by the good book with 2 advantages:
The resulting classes can be used from languages other than Visual C++.
The details of the COM interface can be hidden from the managed client code. .NET data types can be used in place of native types, and the details of data marshaling can be performed transparently inside the custom runtime callable wrappers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Note: I know the question title is suboptimal. Feel free to improve.
Thrift enables serialization as well as RPC. However, unlike systems like COM or CORBA or ZeroC ICE, ... it does not have the notion of a remote object or remote interface in a polymorphic way, therefore all services defined in a Thrift infrastructure are just collections of functions.
Thrift Features
Thrifts Non-Features state (interface?) polymorphism as a non-goal which is fair enough, but ...
As a programmer in languages that make natural use of objects in that I can have functions that return other objects (or interface-references), not just structs, this appears to be a bit awkward in that this would mean that all "object" functionality in a thrift service would have to be provided by functions additionally taking handles as input parameters to define what is being operated on -- a bit like doing OO in C :-)
Imagine a thrift service operating on files. It's interface would look much more like what C has (fopen etc.) than what we use today in C++, C# or possibly even Python.
Of course one could write additional wrappers in the target language, but you don't have any support from the Thrift framework, so that's what I'd call "awkward".
Phrasing it another way: Is dropping back to a purely procedural interface on the remote service level an issue?
To give this yet another twist: Even when I use the REST interface of, say, Jenkins, the URL based interface I have feels slightly "OO", as I access job objects by URL name and then specify the operations on them by GET parameters. That is, to me, it seems a string based REST approach can capture operations on resources (objects or interfaces if you like) much more naturally than a purely procedural interface. It is totally ok for Thrift to define that out of scope but it be good to know whether users find it a noticable thing.
This is a question to active Thrift users: Is the problem I describe above an actual problem in day to day use? Is it an observed problem at all?
Is this a general "problem" with SOA?
My impression is, that you mix concepts in an incorrect way and then try to draw conclusions from that.
RPC is nothing more than a remote procedure call. This means exactly that: Calling a remote piece of code, passing some arguments and getting some results. That's all. How to interpret these data is an entirely different thing.
In an OOP context, every method call (including RPC, but not limited to) is a procedure/function call with an additional hidden argument typically called this or Self. What really distinguishes an object from non-OOP code is the ability to do information hiding, derive classes and override methods, and some other nice stuff. Behind the scenes everything is just data, which becomes painfully obvious when you have to de/serialize your objects into e.g. a database - in most of the cases you will use an ORM of some kind for that task. An RPC mechanism is on an equivalent plane. What frameworks like COM or CORBA do behind the scenes is nothing else, they just hide it better from you.
At least with COM, you are not dealing with objects. You are interacting with interfaces, which are typically implemented as objects. It is hard to tell whether or not a particular interface is part of the object, or if it is added by aggregation or composition. Even the opposite can be true: It may be the case, that two otherwise unrelated interfaces may be implemented by the very same object instance for some reason. Interfaces have more in common with services than they have with objects.
SOA is not limited to RPC. For example, a REST-based interface is not considered RPC by a lot of people (although one can argue that point) and does not offer any objects that would deserve the name, yet you can do SOA with REST. And of course, SOA is also not limited to neither COM or CORBA environments, nor to SOAP or XML-RPC interfaces. SOA is primarily about services (hence the name), not objects. To put it into one sentence, RPC, OOP and SOA are different concepts, and comparing them to each other is what is called a category mistake.
How the server and client code represent your data depends on the system used and the traits of the target language. Don't let yourself be confused by the naming of the IDL entity - a struct in the IDL is not necessarily a struct in code. For example, using Thrift and C# as the target language, you get neat partial class-es generated from a struct, easily extendable with some manually written code. This may be different with another target language (say plain C or the Go language) and another system like Protobuf, Avro or the REST client of your choice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am a wanna-be Games Developer and I prefer using C#. When I asked what the disadvantages of writing real-time applications in C# were I got 1 significant point back: Garbage Collection and the unpredictable impact it can have on performance.
My counter question is, what about Unmanaged C#? How does it compare (performance-wise) to C++? Is it a valid option for developing software?
I don't hear much about unmanaged c# and all the "unmanaged c# versus C++" questions I saw were unanswered or answered inaccurately. These questions were not on stack overflow.
EDIT:
I believe umanaged C# is "Unsafe Code".
Unsafe code in C# is not for developing separate applications. You can use unsafe code for some kind of time-critical operations, but generally it's not the most effective and the most convenient way of doing this. IMHO, it is primarily designed to give C# an opportunity to integrate with unmanaged dynamic link libraries and unmanaged code, so from my point of view the primary reason is INTEGRATION.
I can see 3 common ways of managed and unmanaged code integration:
Unsafe code in C# and P/Invoke. Build C# wrappers over compiled unmanaged DLLs.
Managed C++. Build managed assemblies over existing C/C++ code.
COM interoperation. Call Runtime Callable Wrapper from .NET client or call COM Callable Wrapper from COM client.
On the other hand, it's your architectural and conceptual decision: if you need a full memory and performance control, you develop in C++ or even pure C. If you need advantages and simplicity of modern language and modern technologies, you develop in .NET C#. Or you can use both, and how to integrate them is described above.
You can use C# to build games. The question is what exactly are you intending to do? What platforms do you intend to target, and how polished do you intend the finished product to be?
Others have mentioned Unity, which uses C# and provides a ready-made game engine and development suite. The only downside is that the free version has limitations.
If you want to build your own engine for the sake of understanding, look into XNA. Or you can use a wrapper around OpenGL like SharpGL. Or maybe you can find the long-dead Managed DirectX floating around somewhere. Or if you are really brave, you can use unsafe code and wrap GDI calls so that you don't have to deal with the horribly slow GDI+ implementation. The last two really aren't recommended, and only XNA is going to provide you more than a way to draw things on the screen. There are sure to be countless other possibilities, especially considering what becomes available to C# developers with Mono.
Whatever you decide, the garbage collector isn't going to get in your way, and unsafe code wouldn't be a solution if it did.
Edit:
As mentioned by cdoubleplusgood, XNA is no longer in active development. Look into Monogame and consider the wonders of cross-platform development a bonus.
For general purpose applications C# (managed) is a very suitable language with great performance. Unless you have extremely high demands you can certainly use it for games. Have a look at Unity:
Unity
Nevertheless, most AAA game studios use C++ as their main programming language. That being said, if you want a career in such studios you are better off investing some effort in C++.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm supposed to work with Open CV, which can be programmed in C++ and deploy it in a .NET graphic interface application. I'd really like to work with C # for the interface traits.
What's the best approach for this?
I know of two ways that C# and C++ can be used in the same application.
The simplest way works where the components to be written in C++ and C# can be separated such that one component relies on the other, but they are not mutually dependent. In this case just create two assemblies, one in C# and one in VC++, and reference one from the other. This is the simplest way to do it, not least because it is supported in the UI of Visual Studio.
However, that approach will not work if there is a mutual dependency, ie, class A needs to know about class B and class B needs to know about class A, where class A is to be written in C++ and class B is to be written in C#. It is still possible to write the classes in different languages like that, using a lesser known feature of .NET called multi-file assemblies, or netmodules.
See How to: Build a Multifile Assembly and Multifile Assemblies for instructions. It is useful to remember that the C++ compiler is generally more clever than the others. I seem to remember the procedure was to get C# to compile its half to a NetModule, then pass that to the C++ compiler and linker which was capable of linking it to the C++ parts and creating the final assembly.
An alternative approach, if you only intend to write a small amount of C# code, would be to learn the VC++ syntax for the .NET features you want to use and avoid C# altogether. VC++ can declare managed interfaces and types just like C# can, and if you will not be writing much actual code in C# then this might be easier.