I have a set of struct definitions that are used by both C# managed components and unmanaged C/C++ components. Right now, the identical struct definitions exist separately in C/C++ and C# code - causing duplication and related chaos. What's the best way to maintain single definitions that can be used from both C# and C/C++?
Thanks!
Amit
P.S.: I'm a C/C++ guy so if there's an obvious way to do this, I might be missing it completely!
I'm not familiar with your project(s), obviously, but have you considered building a managed bridge for your library in C++/CLI? With the "It Just Works" hackering the C++/CLI compiler does for you, many times you'll be able to marshal and share managed types with native code and back and forth.
Again, I don't know if it's right for you without more specifics, but it might be worth looking into.
you need a IDL (interface definition language) try googling:
protocol buffers.
ICE (internet communication engine).
Perhaps Microsoft COM ?.
--edit: new entry -- it appears microsoft has an IDL compiler.
It all depends on what you want. all the above technologies have an IDL element to them, and come with their own set of baggage. I personally would stay low level C/C++ :D. So I would Google "Imatix GSL" and use the mentioned technology to model the problem in XML and generate the data structures in any programming language -- this technology is very simple and subtle and requires an experience programmer so if it doesn't make sense you should stick with an IDL.
-- edit: programming technique --
You can solve the problem by pure technique if you like. Chaos ensues when the rigor of engineering breaks down. If you make a decision to firewall and encapsulate the problem into pure C/C++ code you won't have to worry about the interface falling appart in your dependant code -- this is because any usefull language can interface with the ABI of your platform (simple C functions :P). The crux is not to expose internals, but just an interface with opaque types, such as numeric handles that represent objects and functions that may be performed on your types.
I once wanted to do so in one of my projects that had a hard separation between C# code and C code. Ideally, the C# code would have borrowed header files from the C code but:
since C# doesn't support include, I don't see how you could share the definition of a structure and include it both in your C# or C/C++ code
having my structure definitions in separate headers wasn't convenient anyway
I didn't want to rely on IDL or custom "parse the C headers and only extract structures definitions" preprocessing step
Related
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. ;)
We have a large project mainly written in C# (services, multithreading etc.). However, the core number crunching algorithms are written in unmanaged C++ to be fast (OpenMP etc.).
Unfortunately, at the moment we have to do a lot of effort to exchange data between these two worlds. I.e., we have to write wrapping classes in C++/CLI for each of the C++ classes. For (virtually) any required setting (Properties) in the C#-"world" there is a copy in the C++ world (a header file) and an explicit conversion back and forth in the wrapper class. This architecture seems very inefficient and quite error-prone.
Primary question:
Is there a way to share a C#-class with properties somehow automatically in unmanaged C++? (we have to read and write!)
Secondary question:
Could you give any advice of how to improve the architecture in a case as described above. One consideration of ours was to completely switch to C++, but having to find appropriate libraries and write clean code for all the (system-)things we do in .NET at the moment does not feel good.
Many thanks for your help and best regards,
Jakob
I am dealing with similar issues at my work where my primary task is to write managed interfaces to certain high perfromance, low latency dlls, this involves simple cases where I have to wrap the native classes using simple c++/cli containing a raw pointer to the native class or more complex issues where the native code is a server side publisher and the managed code has to subscribe to it using delegates ie they have to be converted to native callbacks.
.NET under the hood is a sophisticated COM server as far as I know. It is possible to write .net assemblies with the ComVisible attribute set to true then it acts as a classic COM component and then it is possible to use it from the native C++ code as a COM component. The reverse that is to use native code from managed can be achieved using the DllImport attributes and all the Marshaling can be fine tuned by the various attributes like the StructLayoutAttribute (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute.aspx) and the MarshalAsAttribute (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx)
I am also using sometimes the unsafe keyword as well. I have to deal with high performance code so in some cases it is that after profiling that I know which is the best solution. Whether it is the warpper class solution that you have mentioned or the classic COM way, or some kind of hybrid with some caching, object pooling etc.
Hope that helps. :)
Apologies if that looks a bit disorganised. It is very late here. :)
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.
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.
I have been keeping up with .NET CLR for awhile now, and my language of choice is C#.
Up until recently, I was unaware that C++/CLI could produce "mixed mode" executables capable of running native and managed code.
Now knowing this, another developer friend of mine were discussing this attribute and trying to determine when and how this ability would be useful.
I take it as a given that native code has the capability to be more efficient and powerful than managed code, at the expense of additional development time.
In the past, I resorted to strictly native C++ code libraries and used Interop to make use of the functionality I wrote into the native library.
I can see the benefit of not requiring an additional library, but I'm curious as to what all the pros/cons of using C++/CLI over soley managed executable created in C#, or such an executable using Interop to call a purely native C++ library?
(Sidenote: Are the terms Interop/PInvoke interchangeable, as I d.on't understand the difference between the terms, simply seen them used the same way.)
With C++/CLI you can create, broadly speaking, three types of objects:
Managed types. These will compile down to essentially the same IL as the equivalent C#. There is no performance opportunity here.
Native types. Compiles down to native code as if you'd used straight C++.
Mixed mode types. These compile down to managed code, but allow you to refer to native types too.
You might think of (3) as being like writing C# code with PInvoke code to accessing the native stuff - except all the PInvoke stuff is generated for you.
There's more to it than that, of course, as well as some caveats - but that should give you an idea of how it's useful.
In other words it's really a glue language. While you can write fully fledged apps in C++/CLI it's more normal to keep the managed and native parts separate and use C++/CLI to bridge the two more cleanly than with PInvoke.
Another common use is to extend and existing, native, C++ code base with .Net library calls.
Just be careful that you partition your code well as it can be quite subtle sometimes in compiling your pure C++ code down to IL transparently!
As to your sidenote: PInvoke is a particular type of Interop. Interop comes in other forms too, such as COM Interop. In fact, more accurately, PInvoke is a set of language features that make Interop with native code easier.
I've used Managed C++ (the .NET 1.1 precursor to C++/CLI) effectively in the past. I find it works best when you have a native C or C++ library you wish to use in managed code. You could go the whole Interop/PInvoke route, which makes for some ugly C# code and frequently has marshalling issues, or you could write a managed C++ wrapper, which is where C++/CLI really shines.
Because C++/CLI is managed code, you can call it from C# (or VB.NET if you lean that way) in the normal way, by adding a reference to the .DLL. No marshalling, no dllimport, nothing goofy like that. Just normal project references. Additionally, you get the benefit of static linked libraries if your native library is so designed, which is a Good Thing (tm).
Phil Nash really hit the big things. Here's one more that I've hit more than once and is the primary reason I've used C++/CLI in the past:
Some applications are extended by checked all DLLs in some location for exported functions with a particular name. In C#, there's no way to declare a native C-style export, but you can in C++/CLI. I create a "wrapper" in C++/CLI that exports the method, handles any translation of C structs to managed objects and passes the call on to an assembly written in C#.
There are certain types that are not available to other languages, such as templates,
const and tracking handle of boxed value types.
templates are specialized at compile-time. generics are specialized at runtime. Although CLR should cache generics specialization for future use (so you get the same List each time you use it), there is still a performance hit each time a generics specialization is requested.
i know other languages discard the const attribute, but have compile time checking in your C++ code is better than nothing.
Having a type like int^ allows you to access the memory on the managed heap directory without unnecessary unboxing. This can help performance when passing tracking handles of boxed values to functions that expect a tracking handle, such as Console::WriteLine(Object^). Of course the early boxing initialization can not be avoided. In other languages you can store the reference in an Object variable and pass it around to avoid unboxing, but you lose the compile time type check.