Hi all,

I don't want this to regarded as another "which is best question". It's more a "advice needed for the best way to achieve my general goals" or something like this.

A little rough background..
I develop a lot with embedded stuff (PIC MCUs etc) using assembly and C.
I also write native stuff for PC (Windows) in C/C++ too, but I am still learning here (In order for me to have full control/understanding over the development of devices and their PC software - to give an example we are working on a USB oscilloscope). I also know a little bit of VB.Net and have developed apps in VB and C++ using .Net.

Basically I like the idea of using ONLY C++/CLI to delevop in .Net, as I need the convenience of .Net with the power of native C++ too.
Or I thought I could use something like C# or VB and if I ever need to do something they cannot do, write it in C++ and call it in.

The question I am leading up to is. What would be the best way to write quickly in .Net but still have power and be able to get to the lower layers if needed? For instance, I would like to write a small test tone generation app that needs to control the individual amplitudes of samples directly, maybe other similar low level stuff too. What is the best way to go about this kind of thing? - write the main app in C# and call the lower level routines in C++?
How much control do I lose with any of this? - I would like to have as MUCH control as possible, and am not worried about complexity or learning another language to achieve this.

Any advice would be most appreciated, I have been reading all sorts of stuff on the subject, but a lot of seems to just be unfocused argument with people generally supporting what they already know, so it's hard to trust it. I also know that Microsoft do not "recommend" developing full .Net apps in C++, but then why have they provided C++/CLI - I'm also a little worried they may drop C# or VB like they did Java too (I know it seems unlikely, but they are far "newer" than C++). Stuff like QT seems like a nice cross platform option, but I don't know enough of it to judge well (only used it a few times).

Thanks,

Oli

Hi,
I won't give a definite answer, but here are my thoughts on this.

Firstly, while C# and VB.Net perform practically the same, there is much more code available for C#, so I would recommend learning it. It's not hard if you already have a C++ background.

Secondly, C# (or VB.Net for that matter) might be fine for what you're doing. The performance of C# is often underrated. Parallels are drawn to Java, believing they both run in a virtual machine, but C# is in fact compiled into native code at runtime, which is fundamentally faster. It is often even comparable to C/C++ in some cases. However, signal processing might indeed be a weak spot for C#. If you have time to try it out and do some tests, then I'd recommend doing so.

A pretty good solution is to create two assemblies. The main executable written in C# and another .dll in C++/CLI that does the performance-critical stuff. So you get the convenience of .Net with the power of native C++ and also the chance to do custom optimizations in x86 assembly. This is probably your best bet as well. Note that IntelliSense as well as WinForms support was dropped for VC++ in VS 2010, so it's definitely easier to write most .Net stuff in C#.

The C++/CLI assembly can also be linked to other native static or dynamic libraries. Native dynamic libraries (.dlls) can be called directly from C# using P/Invoke (platform invoke), but that's somewhat slower and less convenient.

Microsoft discontinued Java because of legal issues, but I see no reason for MS to drop C#/VB.Net, because these languages have become a major selling point for them. Actually, C++/CLI is less of a priority, which is why IntelliSense for C++/CLI was dropped, but it's still the best way to do interop with native code. Microsoft's policy is probably to enforce C# as the main language for .Net development, VB.Net as an easy starting point for beginners and to keep C++/CLI for the native stuff.

I'm not a big fan of QT or GTK+, since they're kind of bloatware. They're fine for cross-platform development though.

Thanks for the reply,

Since I posted a couple of hours ago, I have started hammering through a book on C# - I forgot how convenient and quick the (proper)Intellisense etc is(from using VB), and the syntax and stuff looks like no problem if you know C++, so it's just getting to grips with the garbage collector and stuff like there being no destructors or pointers (I know you can use them if you want to, but it seems it's recommended otherwise in general). Thanks for the heads up about the Intellisense (and WinForms, that's a definite problem) being dropped in VS2010, I'm still using VS2008 at the moment so I was unaware of the developments.

Nice to hear performance is generally pretty good. I did get the idea from what I've read that C# is not too much slower than C++/CLI for most stuff, and can be faster in some cases. I understand the JIT and MSIL etc are not the same as Java, as some people seem to think.
Also nice to hear that it's unlikely that Microsoft will be changing their outlook for a while as regards dropping C# or VB. Looks like one of these plus C++ is a decent way to go for windows programming.

I was thinking that the "best" way to have the power without having to sacrifice endless hours writing "extra" code would be to write the more performance critical stuff in a dll then call it, as you point out. As long as I still have the ability (with not too much effort) to delve into the lower layers of windows when necessary, then all is fine - this is what my biggest concern was. I guess the way I will approach it is just to dive in to the C#, and deal with anything it might not be able to do as it comes up. Can't hurt to have another string to my bow as regards languages anyway, the worst that can happen is I learn something