Author | Message | Time |
---|---|---|
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? | June 16, 2004, 2:42 AM |
Mephisto | I'd recommend using the .NET framework for development. It's a truely innovative idea and Microsoft developed it quite well. | June 16, 2004, 3:10 AM |
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. | June 16, 2004, 3:22 AM |
Mephisto | [quote author=Moonshine link=board=30;threadid=7274;start=0#msg65435 date=1087356146] 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. [/quote] 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... | June 16, 2004, 5:51 AM |
Moonshine | [quote author=Mephisto link=board=30;threadid=7274;start=0#msg65447 date=1087365119] [quote author=Moonshine link=board=30;threadid=7274;start=0#msg65435 date=1087356146] 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. [/quote] 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... [/quote] If you say so... | June 16, 2004, 6:09 AM |
Mephisto | [quote author=Moonshine link=board=30;threadid=7274;start=0#msg65448 date=1087366180] [quote author=Mephisto link=board=30;threadid=7274;start=0#msg65447 date=1087365119] [quote author=Moonshine link=board=30;threadid=7274;start=0#msg65435 date=1087356146] 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. [/quote] 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... [/quote] If you say so... [/quote] Yes, I do say so. But I may be wrong, so please correct me if I am... | June 16, 2004, 6:14 AM |
Yoni | I'll have a "Don't touch it" on the .NET and the Longhorn please. | June 16, 2004, 5:58 PM |
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.... | June 16, 2004, 6:15 PM |
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. | June 16, 2004, 7:23 PM |
Yoni | [quote author=K link=board=30;threadid=7274;start=0#msg65508 date=1087413791] I tend to write completely unmanaged C++ code; if I wanted to write managed code I'd write it in C# [/quote] .NET is such MIND CONTROL. My C++ is managed, damn it! | June 17, 2004, 6:16 PM |
K | [quote author=Yoni link=board=30;threadid=7274;start=0#msg65646 date=1087496200] [quote author=K link=board=30;threadid=7274;start=0#msg65508 date=1087413791] I tend to write completely unmanaged C++ code; if I wanted to write managed code I'd write it in C# [/quote] .NET is such MIND CONTROL. My C++ is managed, damn it! [/quote] Yes, but not managed by the .NET framework. Managed by you. ;) | June 17, 2004, 7:10 PM |
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. | June 17, 2004, 7:43 PM |
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. | June 21, 2004, 7:14 PM |
Myndfyr | [quote author=DarkVirus link=board=30;threadid=7274;start=0#msg66537 date=1087845254] 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. [/quote] 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] public unsafe static byte[] Crc32(byte *pBuffer, uint nLength); [/code] 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. | June 24, 2004, 2:34 AM |