I have around 5 C++ DLLs which have thousands of functions and so on. So the thing is, I kind of fell in love with WPF which is in C#(as I understand). But this is another language, so after doing a bit of research I found out that I could create a wrapper, and so I did(The wrapper was created in C++/CLI). The wrapper has some few conversions, and it worked fine. I also heard about Pinvoke, but my problem with all of these is that what if I don't have time to convert thousands of functions and variables? What do i then do? Is there some kind of fast way?
PS. Im using Visual Studio 2012
Thank You
You may want to check out SWIG.
SWIG is a software development tool that connects programs written in
C and C++ with a variety of high-level programming languages.
Related
I have C++ Qt application together with a lot of .net C# assemblies, that I would need to use in the C++. Before doing any research I was expecting there is existing solution to generate C++/CLI wrapper DLL for usage in pure C++ app, but to my surprise I wasn't able to find anything except SharpCpp, but that's just experiment.
As the amount of classes that need to be exposed might be pretty extensive, I was looking for as much as automatic solution possible ( like what I'm used to when wrapping C++ for Python using shiboken)
As far as I can tell my possibilities are (as just compiling the app with /clr is not an option):
Manually write C++/CLI bridge DLLs, but this could take a lot of time.
use COM, but that would also mean a need to implement the COM exposure to all C# assemblies also. Or is there any automated solution?
use CLR Hosting. Not an option without automatic generation of the wrapper also.
try using something like Alter-Native or cs2cpp, but I don't know how much production ready this is.
So I was wondering, if someone was facing similar problem, and what turned out to be the best, and most maintainable solution.
I want to start making VSTi's, more specifically, midi ones - those who don't produce any sounds but just output midi data to other vst plugs (arpeggiators, chord tools, etc).
Now I've just bought books for C# thinking it would be a nice language to begin with (not just for vst programming), but everyone keeps saying C++ is the way to go, and VST.NET seems to be for C++....just seems everything is going against me on my C# road?
I have the "programming thinking" in my head but it was years ago since I programmed, Visual Basic, Turbo Pascal, and such. So I'm at a pretty clean start.
What's your advice here, sell my new C# books (or hide them in the bookshelves) and aim for C++, or is C# still ok? I've always thought C++ is alot more complicated than C#, to learn.
By the way, say the VST.NET SDK for C++, can it be used for C# in some way?
VST.NET is not for C++. Where did you get that idea? Go to the code of VST.NET and check out the samples. That will make things clearer - I hope.
Hope it helps.
Marc
Author of VST.NET and MIDI.NET
Steinberg's VST plug-in architecture has been around a long time, first released in 1996. .NET of course would take another 6 years so of course a lot of sample code is in C++. VST v3 uses COM to make it easier to develop plug-ins in languages other than C++.
There are two kinds of COM, the "pure" kind that's based on the IUnknown interface. And the "practical" kind that's based on IDispatch, otherwise known as OLE Automation or ActiveX, these days just called Automation since the name recognition for "ActiveX" no longer instills confidence :)
The C# language works very well with the "practical" kind. Which supports type libraries, a file format that describes the types implemented by a COM server. Very easy to use in a C# program, you simply add a reference to the type library and it acts like just a normal .NET assembly. VSTs however use the pure kind, you don't have the handy type library available to import the interface declarations.
Writing plug-ins in C# is still possible, you have to re-declare the VST interface types in the C# language or use a C++/CLI wrapper to bridge the gap. Pretty painful to get this right, but it has been done before. Like in this open source project. Or this one. No idea how good they are btw, not an endorsement. The first link is for VST.NET. It is a managed wrapper, not for C++. After it is compiled anyway, it uses C++/CLI to take care of the native interop. The second wrapper isn't exactly usable anymore since it requires the Steinberg SDK. Which was discontinued just recently. Ominous sign of course.
I'd like to second Obiwanjacobi. I've been using VST.Net for several months, and it is excellent.
There's certainly an argument for using C++ because it does allow finer grained control of CPU optimization. But, it's a myth to say that C++ code is necessarily faster than C# code. C# does a lot of the hard work for you like memory management and so on. Basically, when someone says C++ is faster than C# they are not really comparing apples with apples. But, nonetheless, language is a personal choice.
I thought I'd add this link because if you are going to create VSTs, you will need controls. Here is a set of controls in the beta phase. They are designed for VSTs. They are skinnable and light weight.
https://bitbucket.org/MelbourneDeveloper/vst-controls-.net
If working with one specific dll, use p/invoke to create a wrapper, implementing functions as detailed in the VST SDK.
If using a generic method for a set of VSTs, create a mixed mode ref class wrapper, passing the filename as an argument - you need to do this in C++. This class marshals data between managed and unmanaged memory.
Since VST3 is the latest VST standard, and is COM compatible, instantiate using COM. For some ideas, see How do I go about instantiating a COM Object in C# by CLSID?
The reason is simple. C++ is one of the lowest level high level languages. C# and Java are often the best tools for a web app or a business app. Never for a multimedia app where the size of the footprint is exponentially and inversely proportional to its performance. ;)
I am just looking at the options for now but I have a large number of C libraries that were written in Visual Studio 6 as statically linked .lib. Newer development needs to be done in Visual Studio 2010 that will call these libraries and it has been decided that although there are possible solutions to calling these old libraries, that they should be updated to Visual Studio 2010. As part of that conversion, it is looking likely that we might as well convert them to an OO language. Whether that be C++, C++/CLR or C# is up for discussion.
New applications may be written in C# that will call these libraries.
What would be best to convert the libraries to? It also needs to be a fairly straightforward (i.e. not too time consuming) option. I think converting them to C# will be too much work. Unmanaged C++ would be the easiest but would C++/CLR be a good middle ground? I am thinking here that it is easier to call C++/CLR from C# than unmanaged C++ and therefore would be worth the little more work here
Rewriting from scratch is not an option. There are over 100 libraries
and a lot of code.
If rewritting them is not an option I don't understand this statement.
As part of that conversion, it is looking likely that we might as well
convert them to an OO language. Whether that be C++, C++/CLR or C# is
up for discussion.
You cannot "convert" C code to C# and/or C++/CLR code. The only correct term would be a total and complete rewrite. It sounds like your better of just loading the project in the newest visual studio and compiling it as is.
If it already works there is no reason to change the language the dll is written in.
By the sounds of it...You don't seem to be familar with any of the languages your suggesting considering you had a question about the term unmanaged C++.
We have already gone down the route of leaving these libraries as C
written in VS 6 and trying to call them from C# written in VS 2010. It
got a little messy and it was decided that this was not a good long
term direction.
This means your only real choice is to rewrite the libraries so they are easier to work with. Just switching to C++ will not solve the problems you ran into. You can use C style conventions within C++ without an issue.
I have worked extensively with C#, however, I am starting a project where our client wishes all code to be written in C++ rather than C#. This project will be a mix between managed (.NET 4.0) and native C++. Being that I have always preferred C# to C++ for my .NET needs, I am wondering if there are any important differences I may not be aware of between using C# and managed C++?
Any insight into this is greatly appreciated.
EDIT Looking at Wikipedia for managed C++ code shows that the new specification is C++/CLI, and that "managed C++" is deprecated. Updated the title to reflect this.
C++/CLI is a full fledged .NET language, and just like other .NET languages it works very well in a managed context. Just as working with native calls in C# can be a pain interleaving native C++ and Managed C++ can lead to some issues. With that said, if you are working with a lot native C++ code I would prefer to use C++/CLI over C#. There are quite a few gotchas most of which could be covered by do not write C++/CLI as if your were writing C# nor write it as if you were writing native C++. It is its own thing.
I have worked on several C++/CLI projects and the approach I would take really depends on the exposure of different levels of the application to native C++ code. If the majority of core of the application is native and the integration point between the native and managed code is a little fuzzy then I would use C++/CLI throughout. The benefit of the control in the C++/CLI will outweigh its problems. If you do have clear interaction points that could be adapted or abstracted then I would strongly suggest the creation of a C++/CLI bridging layer with C# above and C++ below. The main reason for this is that tools for C# are just more mature and more ubiquitous than the corresponding tools for C++/CLI. With that said, the project I have been working on has been successful and was not the nightmare the other pointed to.
I would also make sure you understand why the client is headed in this direction. If the idea is that they have a bunch of C++ developers and they want to make it simpler for them to move to write managed code I would posit to the client that learning C# may be less challenging then learning C++/CLI.
If the client believes that C++/CLI is faster that is just incorrect as they all compile down to IL. However, if the client has a lot of existing or ongoing native C++ development then the current path may in fact be best.
I've done a project with C++/CLI and I have to say it was an abomination. Basically it was a WinForms application to manage employees, hockey games, trades between teams, calendars etc, etc...
So you can imagine the number of managed controls I had on my forms: calendars / date time pickers, combo boxes, grids etc.
The worst part was to use only C++ types for my back-end, and use the managed types for the front-end. First off you can't assign a std string to a managed string. You'll need to convert everything. Obviously you'll have to convert it back...
Every time I needed to fill a grid, I serialized my C++ collections to something like a vector<std::string>, retrieve that in my UI library and then looped trough that and made new DataGridRow to add them to the grid. Which obviously can be done in 3 minutes with C# and some Linq to SQL.
I ended up with A+ for that application but lets be honest it absolutely sucked. I just can't imagine how pathetic the others app were for me to get that.
I think it would've been easier if i used List<Customer>^ (managed List of some object) in my C++ instead of always converting everything between vectors of strings. But I needed to keep the C++ clean of managed stuff.
/pissedof
From using all three areas (.NET, C++/CLI and C++) I can say that in everyway I prefer using .NET (through C# or VB.NET). For applications you can use either WinForms or WPF (the latter of which I find far better - especially for applications that look far more user friendly).
A major issue with C++/CLI is that you don't have all the nice language features that you get in .NET. For example, the yield keyword in C# and the use of lambda (I don't think that's supported in C++/CLI - don't hold me to that).
There is, however, one big advantage of C++/CLI. That is that you can create a bridge to allow C# and C++ to communicate. I am currently working on a project whereby a lot of math calculations and algorithms have already been written (over many years) in C++, but the company is wanting to move to a .NET-based user interface. After researching into various solutions, I came to the conclusion that C++/CLI was far better for this. One benefit is that it allowed me to build an API that, for a .NET developer, looked and worked just like a .NET type.
For developing an application's front end, however, I would really not recommend C++/CLI. From a usability point of view (in terms of developer time when using it) it just isn't worth it. One big issue is that VS2010 dropped support for IntelliSense for C++/CLI in order to "improve general IntelliSense" (I think specifically for C++). If you haven't already tried it, I would definitely advise checking out WPF for applications.
I have a solution with 2 projects:
a c++ main project
a c# project (display simulator)
Today these 2 apps share data using a loopback TCP client/server connection, but that's not very optimal (timing issues..).
I was wondering if there was a way to access the c# data from the c++ project directly and vice versa? (It seems to be possible with 2 c# projects..)
If it's not possible, what's the best way to implement this with shared memory?
thanks!
Michael
EDIT: thanks for the answers. The 2 projects used to be independant solutions and are both executables - I'm actually trying to merge the 2 into 1 solution / executable.
For info: The c++ app is a PC version of an embedded app - the c# app is a lcd/HMI simulator.
Converting the C++ project to a C++/CLI project might be the easiest way to go. Note however that some code doesn't play well with C++/CLI (we've had problems using libraries that use boost::thread in a managed executable).
You can use COM Interop or Platform Invoke to access native code in C#.
If that's not what you're asking for, please elaborate.
Named Pipes?
For interprocess communication via named pipes you can check out the .NET 3.5 feature
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx for the C# side. From the C++ side, I assume you know the equivalent :).
There are two ways I know of to get direct access to memory between c++ and c# without the overhead of marshaling/demarshaling and com. If it is required to keep the c++ part of your code native then the only way I know to achieve this is to host the clr from your c++ application. A relatively complicated undertaking. Google "hosting the common language runtime". Then you can load your c# code as an assembly, call into the c# code and provide a common shared memory style interface. Although you will have to write all of the shared memory support yourself as I have found no direct support for shared memory in c#/.net.
The other way is to compile your c++ code with common language runtime support. This is by far easier and will allow you all the power and glory of c++ while allowing access to clr based data types, and the ability to call back and forth between your c++ and c# code. See "Language Features for Targeting the CLR" in your VS2008 documentation. pin_ptr will become your close friend and ally in this process.