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. ;)
Related
At the moment, I am working in a C++ environment. There are many in house programs, SDKs, and DLLs. What I want to know is, moving forward, would I be able to wrap that code into something C# could use? I'm still learning about wrapping code for other languages, and haven't found a decent source for going from C++ to C#.
As far as cross-language interop goes, the C#-C++ interop is actually quite usable. Check out the official documentation. "Managed" is Microsoft-speak for everything in the .NET runtime, i.e. your C# code; "unmanaged" or "native" means your C++ code.
Microsoft has extensions to C++ called C++/CLI that make it easier to build wrappers for .NET languages.
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.
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
Currently, we are working on a C++ legacy code base, which consists of several software components.
One of the components, are written in a way that is extremely difficult to maintain. (For example, memory allocation is done in X place, but memory de-allocation is done in Y place. This make memory management a painful job). Till now, we able to solve (or workaround) all the memory leakage issues.
However, after several rounds of bug fixing, our feeling is that, due to the high maintenance cost of this software component, we are unable to go too far from current milestone.
I know it might be bad to rewrite the source code : http://www.joelonsoftware.com/articles/fog0000000069.html
However, instead of re-factor the current code, we forsee it will be better to re-write from scratch due to
Till now, no one in the team can fully understand that software component code.
The legacy software component is a small piece of software. 20k lines, I guess
Our teams are pretty clear on the requirement and what we are trying to achieve
Hence, we are planning to go for a managed code, at least make memory management a painless job. We plan to choose C#, as
All our C++ code are compiled using Microsoft VC++
We are using MFC, in other software components. (in DLL form) Every DLL, do have their very own resource.
I am from C++ and Java background, and know nothing much on C#.
How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?
Anything I need to pay attention on it?
Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?
Thanks.
I am in a similar situation and I also did some experiments mixing C++ and C#. The problems in my application however were that:
the application is not clearly split up in different modules, making it hard to move specific modules from C++ to C#
the application is quite cpu-intensive and experiments revealed a big overhead in calls from C++ to C# or C# to C++
Additionally, you cannot call C# directly from native/unmanaged C++, which meant that I had to introduce an additional intermediate C++/CLI (or is this called C++.Net?) layer.
Therefore, I chose not to move to C#, but stay with C++.
So, if you want to move from C++ to C#, make sure:
that you have clearly separated modules
that the transition (calls) from C++ to C# or vice versa are in a place that is not used that often (so not during cpu-intensive tasks)
Additionally, remember that if you are not the sole developer of the project, that all (or most) of your developers should also learn C#. You don't want to delegate all C# code to your latest junior developer, because if he leaves, you will be (or could be) in trouble.
How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?
Not well at all. You can't P/Invoke to a C++ library -- it works with C exports only. You would need to write a wrapper exposing a C library interface for you to P/Invoke from C#, or you'd need to recompile MFC using C++/CLI. There's little reason to do this though as Winforms is a comparable library to MFC for .NET code.
Anything I need to pay attention on it?
I don't understand that question.
Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?
Considering you can't do it using C#, yes. You'd have to recompile those C++ DLLs to have them expose a C interface, or you'd have to recompile them from source using C++/CLI.
Note: No matter what you do here, you're still going to have to worry about memory managment and object lifetime of anything going on inside native code. The CLI does not automatically manage native resources for you.
This question already has answers here:
Is there any advantage to using C++/CLI over either standard C++ or C#?
(4 answers)
Closed 7 years ago.
I have been working as a native C++ programmer for last few years. Now we are starting a new project from the scratch. So what is your thoughts on shifting to C++\CLI at the cost of losing platform independent code. Are there are any special advantages that one can gain by shifting to C++\CLI?
I would recommend the following, based on my experience with C++, C# and .NET:
If you want to go the .NET way, use C#.
If you do not want .NET, use traditional C++.
If you have to bridge traditional C++ with .NET code, use C++/CLI. Works both with .NET calling C++ classes and C++ calling .NET classes.
I see no sense in just going to C++/CLI if you don't need it.
Some questions to consider before switching:
[1] Are you fine with sticking to Windows? There are .NET clones for other OS's, but your app is not going to just run transparently. A complexity you might not need.
[2] Are you considering switching just for the garbage collection support? If so, you can just use some C++ garbage collector libraries. And if you figure out how to leverage std::shared_ptr, you might not feel the need for garbage collectors. An overhead you might not need.
[3] Are you considering C++/CLI because of the garbage collection & all the useful .NET classes that you can leverage? If so, why not just switch to c#. C++/CLI is a transitional technology, and it is best not to invest resources in such things. c# is getting pretty mature and usable.
Personally, I would just stick with C++ ;).
Is there any benefit to you? You will likely lose the ablity to switch to another OS.
don't bother unless you're integrating with .NET apps. Certainly do not use STL/CLR as its performance is truly awful.
Its tempting to flip that switch to use the .NET class libraries, but there are alternatives. If you do this, you will not be able to port your code so easily.
It also seems that the rise of OSS is increasing, so now might be the time to investigate using cross-platform libraries and tools. You can deploy a linux app much more easily than a windows one (by shipping a fully-configured OS!), and you get much better ROI if you deploy linux clients (as they're free).
If I were a businessman, I would be looking to at least have the capability to deploy on linux or mac than just windows-only. Strategically, I would not want to bet that the world stayed with Microsoft in 5 years time.
The main advantage you would get moving to C++/CLI is to get access to the .NET libraries and the framework itself (garbage collection etc.). However, as far as I can tell the main reason C++/CLI exists is to ease the porting of existing C++ code to run in the .NET framework. New projects are encouraged to use C#.
If you need to use existing C++ code mixed in with the .NET framework, then it would make sense to use C++/CLI, but in general you should just begin with C#.
If there is something in .NET that the new project needs to use extensively (maybe simpler GUI design or something), then use C#. if not, then stick with native C++. I don't think you will lose anything by doing that.
I dislike C++/CLI so much that I'd recommend steering clear, as I describe here. Some suggest using C++/CLI as a bridge between standard C++ and C#, but thanks to the way C++/CLI is designed, it is very tedious to use that way (you have to manually create wrappers of normal C++ code that can be called from C#). Therefore, I would recommend SWIG instead for interfacing standard C++ with C# (although admittedly, SWIG has a substantial learning curve).
Take a look at those two articles:
A Critical Overview of C++/CLI, Part I
A Critical Overview of C++/CLI, Part II
I believe that by now you are
convinced as I am that C++/CLI is
neither a "set of extensions to C++"
(in many aspects it’s actually a
subset of C++), nor is it related to
C++ more than any other language with
semicolons and curly braces.
Furthermore, C++/CLI is definitely a
Windows-oriented programming language;
it’s definitely not a language that a
Solaris 10 server or a Nokia mobile
phone will be happy to run. What does
it have anything to do with C++?
One main disadvantage of using C++/CLR is the possibility of losing your IP (intellectual Property) if the code is not obscured suficently. In general I agree with the statements made by other members here. If you want portable code independant of the MS .net vm then native C/C++ is the way to go.