Considering C++ .NET

[_uj]

I need some advice on the implications of using C++ .NET.

Is there some special advantage of using C++ over C# (other than personal familiarity with the one or the other, and that C++ is more source-level portable)?

Can I still make use of non-.NET based libraries (such as Boost and Loki) in .NET code? Or will this result in expensive function calls over some interface?

Is it still possible to write reasonably portable code. I was thinking of trying to restrict using .NET to only the GUI (including DirectX) and possibly the threading part of my application. That would include not making use of the built in garbage collector for example.

Does the above sound feasible. My alternative is to us pure unmanaged code with different support libraries. I was hoping that partly using .NET may make my application more easily adaptable to future changes in Windows technology but still reasonably portable to other operating systems (not the .NET parts of course).

[Lee Cheon-Sin]

.NET code is very portable if written using classes available for both Mono and Microsoft .NET. .NET is available for Mac OS X, Linux, and Windows. Mono doesn't have any support for C++/CLI though (that I know of), but it supports C#.

[_uj]

.NET code is very portable if written using classes available for both Mono and Microsoft .NET. .NET is available for Mac OS X, Linux, and Windows. Mono doesn't have any support for C++/CLI though (that I know of), but it supports C#.

If one wants portability and accepts managed code then Java probably is the better alternative.

What I'm looking for is to give away portability for the GUI/graphics part of my application to get a very tight integration with windows, but I want the rest of the application to be standard C++ and thus source level portable among platforms.

I've realized now that C++/CLI really isn't C++ so I can as well use another language that isn't C++ either, namely C#. It has the additional advantage of being the preferred language for managed code.

So I have 3 different options:

1. C# for tight integration with Windows (mainly the GUI) and unmanaged C++ for the rest.

2. Unmanaged C++ and the MFC.

3. Unmanaged C++ and wxWidgets (a portable GUI package based on MFC).

Well, what do you say?

[Kevin McFarlane]

Seems to me that 2 is the best choice - provided you trust MS to keep MFC up-to-date with respect to Windows UI innovations. If not then I guess 3 is worth exploring. Though I doubt wxWidgets is likely to be as up-to-date as C# with respect to Windows UI innovations.

[_uj]

Seems to me that 2 is the best choice - provided you trust MS to keep MFC up-to-date with respect to Windows UI innovations. If not then I guess 3 is worth exploring. Though I doubt wxWidgets is likely to be as up-to-date as C# with respect to Windows UI innovations.

Thanks. And why not 1?

[Kevin McFarlane]

Thanks. And why not 1?

If MFC or wxWidgets can be as up-to-date with GUI innovations on Windows as C#/.NET then why bother changing languages? Or do you just think you can get the GUI done more productively in C#?

[Microsoftlover]

If your talking about what to chosoe between C++/CLI and C#, i would go for C#, especially because its based towards .NET development, and the class libraries of .NET are created in C# itself anyway. I myself was a C++.NET guy, after C++/CLI came out, i had many problems learning it due to the lack of resources. 6 months after the release of C++/CLI i still found hardly any resources, so i moved to C# and love it here.Also, C# is by far the most effeciant for RAD windows Application Development, especially with its RAD features.