Develop Reference

How to instantiate an unmanaged C++ VST plugin from C# [duplicate]

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. ;)

Managed C++ (C++/CLI) vs C#/VB.NET

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.

Choosing between WPF/C# and Qt/C++ [closed]

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
Me and my team are developing an application, which involves a back-end written in C++ and involves use of libraries such as OpenCV, MIL, etc.
Now, we need to develop a GUI to interface with this program, such that the GUI displays the images, and the user can interact with the images and annotate / mark the images, and then run the image processing algorithms written in C++ to display results.
For the GUI, i am stuck choosing between WPF and Qt
I personally find WPF to be easier, and more powerful than Qt
I understand that WPF is not portable to Linux, but i am not worried about this too much...
Also, WPF uses the DirectX technology, which i may have to use to generate some 3-D visualization at a later stage.
Please help me with these points :
Can I interface WPF directly with C++ (and not with Visual C# ??)
If (Point 1) is not possible, then consider this :
The code in C++ is going to be big, and involving some libraries too, so can i use C# to call C++ functions
Would the time invested in learning Qt be lesser than making my unmanaged non-OO C++ code work with WPF ?
(i have a sinking feeling that I'd have to write too much code for interfacing C++ with WPF, which may equal rewriting half of the actual program itself... :-( )

I've used both Qt with C++ and WPF. I much prefer WPF as a User Interface framework. Qt isn't bad, especially post 4.0. I wouldn't even touch earlier versions of Qt.
As others have said in comments, WPF is better documented, and the online community is larger. If you are looking at styled applications WPF is certainly the way to go. Qt's Declarative language which is new is a good step along that road, but because it's so new it tends to be a bit buggy. WPF has been around longer, and is more mature and richer in features.
However, I think the real issue in your case is the c++ code base that you have.
WPF will require a C++/CLI layer (managed C++) in order to interface properly with your c++ code base. This sounds complicated, and does require a little bit of work, but it is not as crazy as it might sound. And there is tons of documentation about this as well. Personally I would stay away from PInvoke.
Qt is a little easier because it is c++ based, but you will have some translation to do between c++ native types, and Qt types (like QString, QList etc...) that are used internally.
Another thing to consider is what look-and feel you would like for your UI. For example if you were thinking about a nice Ribbon (office 2008, 2010) look, then you will not get this with Qt. Also, there are a ton of third-party WPF controls, but I haven't found very many for Qt. In some cases it is very handy to buy a nice set of controls to supplement the ones Microsoft gives by default.
Over the past couple of years where we don't have a requirement to have a linux UI we have been using WPF, regardless of the code base. We haven't regretted it yet.
However, I will also suggest a third option. Code-jock is a UI framework that is based on MFC I believe. It is c++ and ActiveX based. It has become quite sophisticated. Check it out here.
EDIT:
QML has come a long way since I first looked at it. I haven't had the time to look at it in depth, but from what I hear it offers some very interesting features. It is worth an extra look.
Also, as a few comments have indicated, there are more Office-like controls such as a ribbon, and also some diagram and graphing controls that have added to the Qt toolset. These do make Qt an interesting prospect.
I will stand by something I said earlier though, that as a programmer I find making UIs with WPF a whole lot easier, and I am more pleased with my results than anything that I have ever coded with Qt.

If it's C++, stick to Qt. 3D part of your project can be handled by Qt's OpenGL widget.
Choosing WPF path will force you to do some parts in either C# or VB.net (always bad practice).
There isn't much advantage in using WPF with C++.
Besides, the rest of your code is C/C++. suits your needs.
OpenCV, MIL etc are somewhat easier to integrate with Qt rather than making P/Invoke calls with WPF (which will also cause delays due to .Net marshalling).

I'd say you should stick with Qt if you have a big C++ codebase already. WPF is not as awesome and not as easy to develop as they say. C++ and Qt is a well-known team, plain C++ (not .NET) with WPF is not.

WPF is UI framework and not programming language. You can write WPF application in C# or VB .NET. To use native C++ code from .NET application, you have two options:
PInvoke - allows to call plain C API from native libraries. PInvoke cannot work with C++ classes, only functions. It works by the same way as API calls in VB6.
Using C++/CLI wrapper, you can write .NET Dll which can be used by C#/VB .NET clients. Internally, this Dll uses native C/C++ libraries.
If you feel comfortable with WPF, and don't need cross-platform solution, you can use it. You need to learn interoperability part. C++/CLI is quite complicated language, but programmer who knows both native C++ and .NET can learn it.
On the other side, Qt allows to use any existing C/C++ code directly, and gives cross-platform solution.

Last couple years I have been using SWIG to make pure (unmanaged) C++ DLL's available in WPF applications. It works great, no problems at all, and this is for big applications such as avionics maintenance trainer.
SWIG is great because with one set of interface files (which you write based on your .h header files, so quite easy), you can generate all the scaffolding code to export your C++ DLL to multiple languages such as C#, Python, Lua, Java. SWIG generates the code you need if you want to extend a C++ class from C# or Lua, it handles passing exceptions across languages (so a Lua script could throw an exception that trickle through the C++ layer and get caught at the C# level, for instance), etc. We never have to touch PInvoke (SWIG does it all). It's amazing.
This way, the same SWIG interface allowed us to use WPF (C#, with .NET 4) for the GUI, a native C++ backend (via SWIG) for some existing libraries we had to integrate with, and embed a Lua interpreter to support scripting of the application (via SWIG, same .i interface files, and lua-icxx on sourceforge to simplify interfacing with Lua C API interpreter stack).
I'm wondering how Qt/QML compares to WPF/XAML now, 2 years after this thread started. And I see there is now Qt3D to add builtin 3D as has been available in WPF for a while now (supports 3D canvas natively, without OpenGL or DirectX).

Your WPF code will need to be in C# or VB to get designer and tooling support. Interop between C# and C++ is very good via the use of mixed mode assemblies, which allow you to code a module in C++ that compiles to a mix of managed and unmanaged code. This gives you type-safe interop to your native C++ libraries.
See here for information on mixed mode assemblies. We can vouch for them.
One important consideration IMO is the WPF learning curve. If you can bring your team with you I believe it can be extremely productive.

In the WPF scenario, you would not be interfacing directly from WPF (i.e. xaml views) directly to your unmanaged C++. You would always want to wrap your C++ modules some sort of VB or C# managed wrapper. (You could theoretically use a Managed C++ wrapper, but you'd be mad to do this.) WPF needs thin View Models written in a .NET language at the very least. WPF shouldn't have any access directly to your unmanaged code, so the question is more "can .NET apps interface with unmanaged C++?" and the answer is yes, certainly.
http://msdn.microsoft.com/en-us/library/aa984739(v=VS.71).aspx

About "GUI in C# and code in C++"

First of all, until now, all my programming education, has been targeted to console applications, just like everyone who starts learning C and C++. (the 2 languages i know)
Now, i want to jump to the nice graphical World.
So, I am exploring Windows Forms, i have already got many headaches trying to understand the language that it uses (quite diferent from native C++), but i managed to do a couple of things like using textbox and buttons.
Well, the thing is, i have read in many places that, in order to avoid headaches trying to code winforms in C++, i'd better "Build the GUI in C#, because it's way easier, and the logic, and code in C++". And that is my question, i don't understand that statement, at all.
What is that supposed to mean?
Also, it's C# THAT similar to C++, as to affirm that statement? Cause, if C# was too diferent to C++, i would have to learn the whole C# language
hope you understand my doubt.
PD : Sry about my bad english.

Joan, while it is certainly possible to develop an applications Front End in C# and the logic in C++ I believe it to be a huge waste of effort to do it this way since you only complicate yourself for no real benefit since you can code both things in the same language.
C# has many advantages over C++ and I personally use mostly C#, but I can clearly see many programmers who love C++.
Now going into your question regarding the similarities between C++ and C# the answer is yes and no. Yes in the sense that C#'s syntax is clearly derived from C++. Many things like ifs and for loops are written exactly the same, so if you know how to write an if in C++ you can write it in C#.
The difference (and a critical one that is) lies in the way the languages work. C++ is an strictly compiled language (it goes from C++ code to machine code). C# is an interpreted language (it goes from c# to MSIL and during runtime to machine code). In C# you can't use pointer arithmetic without explicitly allowing, in C++ you can (and will) use pointer arithmetic. C# has garbage collection, C++ does not.
In the end, as I said in the first paragraph you can use both languages to build an application, but it would be highly complicated. My advise to you is to learn a bit of C# and then decide which language you would prefer to build your GUI application. But don't believe even for a second that C++ can't be used to build a front-end since there are a myriad of frameworks for that. One I remember from the top of my head is Qt.
Another option for you is to use "C++/CLI" which is a flavor of C++ which can use the .NET Framework (the same framework C# uses)
EDIT: Thanks Jerry for pointing out that Managed C++ is obsolete and that C++/CLI is the one!

C# has braces, semicolons, and uses the concept of classes. It has "C derived" syntax, but otherwise is very dissimilar to C++. Java is really the precursor to C#, not C++.
You can build application GUIs using C#, and then use various methods of calling into C++ (such as P/Invoke). Unless you are using lots of existing libraries, or looking for absolute performance, its going to be a headache.
If you are looking for examples of modern Windows GUIs using C++, take a look at the Hilo example program.

It is not very difficult to switch to a new language. The few keywords you would have to learn are not the issue. What costs most energy if to get used to the new environment and class libraries. That is probably what you mean and it is true, you'll need some time.
Now coming to the split GUI in C# and code in C++, then you'll have to make all bindings and marshalling of parameters if there are buffers and strings for example. I don't think this would make your life any easier. Interfacing with native Dlls can become some pain. However if you use third party dlls and have already a large working codebase you could try to compile the logic code with /clr enabled. This generates a DLL that can be used from within .NET directly.
NOTE: WinForms is now out-of-date for new applications, consider using WPF instead. It scales nicely, but the learning curve might be steep for newcomers.

Please note that you have native C++ and C++/CLI, the first one is the one you have learned, but the second one is the one you will need to use if you want to combine it with a C# GUI. However, I would suggest you to stay away from C++/CLI because this will cause a lot of confusion if you don't have a solid ground in C++, C# and .NET.
The reason that you can't use the native C++ is because C# is a managed language, so you will either have to find another GUI that fits with C++ or you will have to go C# for everything. For more information about managed see the environment part of Difference between C++ and C#, the article will also provide you with a good comparison between both.

Well, this aint a direct answer but hope it will help you. Since you stated that, you are just started and you want C++ combined with GUI, I suggest you to take a look at Qt. IMO I found C++ and GUI made easy in Qt. Also it's good too.

Although it's not a direct response to the question you're asking, I'd first caution that WinForms are already basically a dead-end, so for new code you'd be much better off avoiding them. If you're going to do a GUI in .NET, the currently preferred choice is WPF.
Some people find C# an easier way to do a GUI. It's definitely true that Microsoft provides considerably more in the way of Wizards and such to do it with little or no coding if you use .NET for the job. Other people (especially those with more experience doing so) can produce a GUI in C++ just quickly (or even a little more so) using C++ instead.
Mixing languages like this can work well in relatively large projects where you have completely separate teams of people working on the different parts. For smaller projects where the same people typically work on both parts, the difference in syntax is at just about the worst possible level -- not enough different to really shift gears and think differently, but still enough different that you can't plan on just typing things and having any hope of them compiling. All in all, you're usually a lot better off picking one language and sticking to it.

Windows API and .net languages

People always advised me that if I am doing some application that should use some Windows APIs to do any process level job, I must use VC++ and not any other .net language.
Is there any truth in that?
Can everything that can be done using VC++ be done in other .net languages also?
Are all the .net languages the same when their capabilities are compared?

If you need to work with native code fairly intimately, C++ is likely to make life easier. However, there's nothing inherently wrong with using P/Invoke to call into the Win32 API from C#, VB.NET, F# etc.
Not all .NET languages are the same in terms of capabilities, although C# and VB.NET are largely equivalent in functionality. I know there are some things which C++/CLI exposes which aren't exposed by C# or VB.NET - I don't know if the reverse is true. (I've no idea what C++/CLI is like for lambda expressions, extension methods etc.)

For most tasks where the class libraries do not provide help, using P/Invoke is usually fine. There are many "rough" APIs out there that benefit from a simple C++/CLI wrapper. It's usually best to do the bare minimum in the C++/CLI code -- effectively massaging what ever ugliness is below for consumption by C#, VB.NET, etc.

When I started programming in .Net, I was using C++/CLI, as I came from a minimal Win32 C++ background. What I found was that I was getting headaches because I didn't understand the fine lines and boundaries between C++/CLI and Win32 C++. Its not as easy as they make it seem to interop between the two. When I learned about P/Invoke, and made my life much easier, and I finally started to progress my skills. P/Invoke is just fine and you don't necessarily need C++/CLI to do that. In my opinion, you either use Win32 C++ completely for low level stuff, or .Net for high level stuff, and I don't really recommend ever trying to interop Win32 C++ with C++/CLI unless you absolutely have to. Even then, its probably just easier to make a Win32 DLL with what you need and P/Invoke the DLL from .Net, or visa versa. Always remember to pick the right tool for the job.