.NET and C++

[Zlixar]

To what extent should i rely on the .net framework in my C++ applications? It's function library is great but as far as compatibility and portability goes... Well that's why I'm posting this.

So post your opinions/thoughts on relying on the .net framework function library in windows apps. 100%? Just for GUI? Don't touch it?

[Mephisto]

I'd recommend using the .NET framework for development.  It's a truely innovative idea and Microsoft developed it quite well.

[Moonshine]

It totally depends on exactly what project you're planning, and other contextual factors.  While the .NET framework can enable you to do things a lot easier than without it, it's unportable and bloated in many areas.

[Mephisto]

It totally depends on exactly what project you're planning, and other contextual factors.  While the .NET framework can enable you to do things a lot easier than without it, it's unportable and bloated in many areas.

I wouldn't go as far as to say it's bloated.  It just has many features, and I don't think there's any features that aren't necessary in .NET.  But yes, it's not necessarily portable, so you'll have to make that decesion whether you want to develop on Windows or if you plan to use Linux or other platforms as well.

You might also want to prepare for the Longhorn release.  Microsoft has claimed that they will be released hundreds of new APIs for .NET.  I found it odd that they could release hundreds of APIs, so this may be false.  But you can probably count on there being several new APIs for .NET integration in Longhorn which will be released in the upcoming future...

[Moonshine]

It totally depends on exactly what project you're planning, and other contextual factors.  While the .NET framework can enable you to do things a lot easier than without it, it's unportable and bloated in many areas.

I wouldn't go as far as to say it's bloated.  It just has many features, and I don't think there's any features that aren't necessary in .NET.  But yes, it's not necessarily portable, so you'll have to make that decesion whether you want to develop on Windows or if you plan to use Linux or other platforms as well.

You might also want to prepare for the Longhorn release.  Microsoft has claimed that they will be released hundreds of new APIs for .NET.  I found it odd that they could release hundreds of APIs, so this may be false.  But you can probably count on there being several new APIs for .NET integration in Longhorn which will be released in the upcoming future...

If you say so...

[Mephisto]

It totally depends on exactly what project you're planning, and other contextual factors.  While the .NET framework can enable you to do things a lot easier than without it, it's unportable and bloated in many areas.

I wouldn't go as far as to say it's bloated.  It just has many features, and I don't think there's any features that aren't necessary in .NET.  But yes, it's not necessarily portable, so you'll have to make that decesion whether you want to develop on Windows or if you plan to use Linux or other platforms as well.

You might also want to prepare for the Longhorn release.  Microsoft has claimed that they will be released hundreds of new APIs for .NET.  I found it odd that they could release hundreds of APIs, so this may be false.  But you can probably count on there being several new APIs for .NET integration in Longhorn which will be released in the upcoming future...

If you say so...

Yes, I do say so.  But I may be wrong, so please correct me if I am...

[Yoni]

I'll have a "Don't touch it" on the .NET and the Longhorn please.

[Zlixar]

And what about using the .net framwork for win32 GUIs? The old win32 windows interface is kind of ugly, and the .NET GUI system works alot better....

[K]

I tend to write completely unmanaged C++ code; if I wanted to write managed code I'd write it in C#, since the syntax is much cleaner.  If you just want to use the .NET framework just for a UI, consider wrapping your unmanaged classes into an assembly you can reference from a managed language, using the System.Runtime.Interop namespace to do COM interop or use external C dlls, or writing your gui in with the native APIs or something c/c++ based like QT or MFC.

[Yoni]

I tend to write completely unmanaged C++ code; if I wanted to write managed code I'd write it in C#

.NET is such MIND CONTROL. My C++ is managed, damn it!

[K]

I tend to write completely unmanaged C++ code; if I wanted to write managed code I'd write it in C#

.NET is such MIND CONTROL. My C++ is managed, damn it!

Yes, but not managed by the .NET framework.  Managed by you.  

[Yoni]

Yep, but they call it "unmanaged" to raise feelings of guilt. "Oh, I'm writing unmanaged code. Shame on me."

I've decided to redefine the term professional code as follows.

Professional code: Code written by Yoni.

Soon, I shall have them on their knees.

[DarkVirus]

If you plan on working with various languages including C++, the .Net framework is very reliable. Not only does the framework allow you to do thinks a hell of a lot quicker than earlier libraries, it's uniformed to work with all languages. I think some people forget the main purpose for the .Net framework. Just be aware that if you write code using the .Net framework that it isn't portable to systems that don't have the framework installed. But I don't think you'll find too many computers without it. There are the select few though.

[MyndFyre]

If you plan on working with various languages including C++, the .Net framework is very reliable. Not only does the framework allow you to do thinks a hell of a lot quicker than earlier libraries, it's uniformed to work with all languages. I think some people forget the main purpose for the .Net framework. Just be aware that if you write code using the .Net framework that it isn't portable to systems that don't have the framework installed. But I don't think you'll find too many computers without it. There are the select few though.

The bonus is that the redistributable is easy to find and easy to get installed.

Part of an issue raised, though, is the use of common language constructs in your particular language.  For instance, in my C# CRC-32 implementation, I included an unsafe method that took a pointer parameter:

Code Select Expand


public unsafe static byte[] Crc32(byte *pBuffer, uint nLength);


That method would most definitely be accessible to C++, but not, unfortunately, to Visual Basic .NET, because it has no mechanisms for dealing with unsafe methods or pointers.  So, remember that just because you're using C++ and targeting the .NET Framework, that doesn't make all of your work 100% compatible with every .NET language.

There are code-access security mechanisms to avoid things like that, though.  For example, on the same method, I applied [CLSCompliant(false)], so that the execution engine would know that the method used additional language features not always present in every language.