Why .NET?
-
It's a tool, not a religion. Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
Yes. Language wars are good fun but a waste of time really. Kevin
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Simon Hofverberg wrote:
VC++ 6.0 (which I like very very much).
VC++6 is utter crap. Totally non standards compliant, given the choice, I would never look at it again.
Simon Hofverberg wrote:
think that everyone should switch from native Win32 C++ development to .NET Framework-based development
I don't think this is true. What makes you say it ? I think that MFC sells itself now, and that Microsoft is pushing C# far more than C++ in general. I don't see any push for C++/CLI, or against Win32. The Express edition only supports CLI, but it's *free*, of course it's knobbled. Christian Graus - Microsoft MVP - C++
-
Chris Maunder wrote:
As always, choose the right tool for the job.
Oh yes. ... but ... I just can't see why we aren't allowed to eat the cake and have it too? There aren't any points on your list that couldn't be solved in a top-class native C++ framework. That would give us all those points plus the extra flexibility, control and speed (in some cases) of native code. And it wouldn't take too much MS muscle power to accomplish that. Put twenty guys in a room for a year with all the resources they need and voilà. /Simon This is not a signature.
Simon Hofverberg wrote:
There aren't any points on your list that couldn't be solved in a top-class native C++ framework.
And what about people who want to use languages other than C++? Or are you saying they should have done .NET plus implement all of the same stuff in native code just for C++ developers? Incidentally, managed code can have impressive performance in many cases. It's a matter of design. I know a very experienced C++ developer, now writing and selling his own framework in Java, incorporating object persistence and agile development. His framework outperforms and outscales Oracle. However, few developers believe him, so he just sells directly to small companies - though he's started to get interest from more high-tech quarters. Another example: Eiffel is a "managed" environment with .NET-like features but compiles to C. Consequently performance is comparable. And there is at least one case study where an app. was rewritten from C to Eiffel and was 10 times faster as a result. I've had a couple of .NET interviews in which the interviewers had rewritten C++ apps. in C# and got performance increases. Kevin
-
Ryan Roberts wrote:
Reflection and attributes are a big plus in .NET though, only way to get close to that kind of power in C++ is to use template metaprogramming, which can get pretty damn hairy.
Template metaprogramming is a pain in the ass. :mad: This reflection thing sounds really, really nice. That's the first thing I've heard about .NET that've really made me want to start using it. But still - why not get that into C++? That would be really cool. /Simon This is not a signature.
But still - why not get that into C++? That would be really cool. Big runtime overhead at a guess :). RTTI is being left as is (i.e bloody useless) in the proposed next version of C++. Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven." - Penn Jillette
-- modified at 8:31 Thursday 16th March, 2006
-
Simon Hofverberg wrote:
why can't I have the cake and eat it too?
Ah, well, that involves a complicated discussion of the big picture. The premise is, Windows sells not only because of the Office and server products that it makes, but because of the thousands of ISV's out there. C++ is a language that the average programmer can get into a lot of trouble with. MFC is clunky and buggy. All the cool graphics stuff requires Avalon, and the graphic "language" to share those cool vector graphics with, XAML, uses (not requires, per se, but heavily relies on) reflection. Couple that with ISV's wanting to write more secure software. So, there's several things going on at once: C# makes development easier because it's an easier language that C++. Build in locking, no pointer management, managed arrays, etc. Designers. Look at the designer support in .NET, leveraging the metadata attributes of the language. Not that I love designers, not that I'm enamoured with entangling my code with all the crap needed to support the visual designers, but it is much more flexible than C++/MFC. Metadata, type converters, so on. C# is managed, supposedly making it less vulnerable to those buffer overrun problems plaguing unmanaged code. Bitmapped controls are going to be a thing of the past, even though I personally couldn't care how sexy the button looks. If it works, it works. But alas, a blocky button doesn't sell anymore. Are you going to use C++ and MFC to render those VG controls? Nope. So the third prong in this is the entire UI experience, which, if you want to take advantage of, you'll probably be using C# or VB.NET, rather than C++. It's possible to use C++, but it still doesn't address the "easier to write in" and "managed" advantages of C#. So, that's my 2c on why you can't have your cake and eat it too. To understand the motivation, I think you have to look at many issues at once, and not just from the programmer's perspective. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
Thanks, Marc! Now this is the most sensible thing I've read about .NET anywhere. And I'm not being ironic one bit (hard to tell in these posts). Thanks!!! You've actually made me quite interested in trying out these .NET things after all. And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ... It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language? Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard (which seems to be barking up the wrong tree with all the template meta-programming stuff, if you ask me) ... Well that's what they tried with Java (change the standard) and it wasn't the way to go so they had to do come up with some new stuff I guess. Or is there some other profound reason behind the VM stuff? Why else make a VM and not just a framework? :confused: /Simon This is not a signature.
-
Simon Hofverberg wrote:
There aren't any points on your list that couldn't be solved in a top-class native C++ framework.
And what about people who want to use languages other than C++? Or are you saying they should have done .NET plus implement all of the same stuff in native code just for C++ developers? Incidentally, managed code can have impressive performance in many cases. It's a matter of design. I know a very experienced C++ developer, now writing and selling his own framework in Java, incorporating object persistence and agile development. His framework outperforms and outscales Oracle. However, few developers believe him, so he just sells directly to small companies - though he's started to get interest from more high-tech quarters. Another example: Eiffel is a "managed" environment with .NET-like features but compiles to C. Consequently performance is comparable. And there is at least one case study where an app. was rewritten from C to Eiffel and was 10 times faster as a result. I've had a couple of .NET interviews in which the interviewers had rewritten C++ apps. in C# and got performance increases. Kevin
Kevin McFarlane wrote:
And what about people who want to use languages other than C++? Or are you saying they should have done .NET plus implement all of the same stuff in native code just for C++ developers?
YES!! That's what I'm saying! But see Marc Clifton's post above, he put in a couple of pointers that I hadn't thought about. /Simon This is not a signature.
-
Simon Hofverberg wrote:
What languages are those classes of applications written in? My guess is 98% C++ (and 80% of those use MFC).
VB has the biggest number of developers. C++ is IMO not necessary for typical business apps. Also, the focus of .NET is largely web and web services development, judging by the job ads. C++ is just too complex and unproductive for such scenarios.
Simon Hofverberg wrote:
Why not give us something like MFC but 1000% better.
There's WTL. I've not used it but many at cp think it's a lot better. You can also use things like wxWidgets and Qt. But why do so many C++ developers tend to think that everything should be done in C++? Kevin
They don't. They think apps that aren't for the web should be done in C++. Web apps should be done in PHP. ------- sig starts "I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
-
fat_boy wrote:
For mission critical I would never considder windows, would you?
Yes, I would, and would even use .NET or Java for the job but it depends on what one considers "mission critical". What about the airport crews? They have to know which planes to service, where they are, what service they require, etc. It doesn't seem "mission critical" but what if they get the wrong information and put too little fuel on a plane that's going to do an intercontinental flight? Or even something simpler, like not delivering the right meals and drinks to the right plane? Or providing the correct information in real-time with all the constant and unforseen changes to passengers? Maybe we'd end up with 200 annoyed people instead of 200 dead people when things do go wrong but it's still important, for them at least. Quidquid latine dictum sit, altum viditur.
Depends on how you define mission critical, if your aircraft maintenance system goes down, the planes dont get maintained. If your air traffic control system goes down, people start dying. Thats my definition of mission critical. You obviously dont have much Windows experiance, or SW experience; Windows does not randomly change data. So a plane would not get the wrong amount of fuel. What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that. It is for that reason I would never trust windows for a mission critical system. Nunc est bibendum
-
Thanks, Marc! Now this is the most sensible thing I've read about .NET anywhere. And I'm not being ironic one bit (hard to tell in these posts). Thanks!!! You've actually made me quite interested in trying out these .NET things after all. And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ... It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language? Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard (which seems to be barking up the wrong tree with all the template meta-programming stuff, if you ask me) ... Well that's what they tried with Java (change the standard) and it wasn't the way to go so they had to do come up with some new stuff I guess. Or is there some other profound reason behind the VM stuff? Why else make a VM and not just a framework? :confused: /Simon This is not a signature.
Simon Hofverberg wrote:
And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ...
Yep. You can call into standard dlls. There's some overhead involved but as long as you keep your design reasonable (ie if calling DoFoo() a million times in a loop put the loop in a native function and only make a single marshalled call isntead of looping in C# and making a million of them) you can still get the bleeding edge native code performance where it's needed most. The biggest problem with adding more stuff to c++ is that after several decades of adding new features onto the specification the langauge itself's gotten extremely bloated with massive numbers of ways to do anything. Starting from scratch let them clean the spec up significantly, granted creaping featuritis is building again, but it's still a far cleaner spec than c++.
-
Thanks, Marc! Now this is the most sensible thing I've read about .NET anywhere. And I'm not being ironic one bit (hard to tell in these posts). Thanks!!! You've actually made me quite interested in trying out these .NET things after all. And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ... It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language? Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard (which seems to be barking up the wrong tree with all the template meta-programming stuff, if you ask me) ... Well that's what they tried with Java (change the standard) and it wasn't the way to go so they had to do come up with some new stuff I guess. Or is there some other profound reason behind the VM stuff? Why else make a VM and not just a framework? :confused: /Simon This is not a signature.
Simon Hofverberg wrote:
And I can still go on writing any amount of stuff I want to in unmanaged code, right?
Yes, that's my understanding, though I've shied away from doing that myself because, if I recall correctly, the managed extensions specifications for C++ have changed. I may be totally wrong here, but I think they are now an official standard. Somebody else can give you more info on that than I.
Simon Hofverberg wrote:
It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language?
That, and the JIT compiler can then generate native assembly code tuned to the processor you're using. That's the vision, who knows what the reality actually is. But it's a slick idea, abstracting the "compiler" output until the code is actually needed for execution.
Simon Hofverberg wrote:
Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard
Because VM doesn't really have anything to do with the language, but the tool that converts the language into machine code.
Simon Hofverberg wrote:
Why else make a VM and not just a framework?
* Processor independence * One IL to rule them all (as you pointed out) * Possibly because it's intertwined with how managed code works Look at it this way. Let's say I write a GC framework in C++. You'd then have to use that framework to instantiate your classes. So, instead of saying
Foo foo=new Foo();which is the same in C# and C++, in C++, you'd have to say something likeFoo foo=ManagedFramework.MakeAFoo();. C++ doesn't specifically make type information available, does it? I guess that's what RTTI is good for. In C#, I could write a general instantiatorFoo foo=InstantiateMyClass(typeof(Foo));, and use the framework's reflection engine to create it (which is what XAML does, and my own MyXaml). I haven't looked at C++ in ages now and so I may be behind the times, but I really don't have a good idea of how that would be done in C++, not to mention all the stuff that has to go on to count the references of Foo and figure out when the things referencing Foo also go out of scope. The point is, there are things that simply can't be done with a framewo -
Airports or air traffic controll systems. If you mean the latter please tell me which airport because I will never fly there. Nunc est bibendum
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Simon Hofverberg wrote:
why should everyone be writing VM (Virtual Machine) code?
I actually ignored the whole .Net and VM thing for a very long time, basically until recently. It doesn't cross over my job very often given speed of 3D graphics under .Net is significantly slower, I had to ignore it. However, technology changes, and techniques and software advance with lessons learned. After a recent presentation of Microsoft for using C# to write combo processing technology using the GPU as a streaming processor and the CPU as support processing, the idea caught on. I have used some of the streaming processor compilers for the GPU, they work well, but require two compilers and two different (slightly different) C varients for CPU/GPU and a lot of annoyances to combine them. By utilizing the same language, although not a public release of "accellerator", Microsoft took this to a level that caught my attention. I have always said I would learn another language "if" it had some value added it to it beyond just another syntax to learn. Microsoft Research did that, so I am learning. That being said, I still use C++ in native code for 3D graphics. I doubt that will change anytime in the future. I'll be going up against several other big-names in 3D graphics visualization this year and performance is my strongest selling point. But I will also be learning C# and .Net finally, it's become something that will be valuable even in the specialty work I do. http://research.microsoft.com/research/pubs/view.aspx?type=technical%20report&id=1040[^] who knows? maybe I will put together a 4 dual-core processor machine with 4 GPUs and have my own mini super-computer solution solver.... :rolleyes: _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Depends on how you define mission critical, if your aircraft maintenance system goes down, the planes dont get maintained. If your air traffic control system goes down, people start dying. Thats my definition of mission critical. You obviously dont have much Windows experiance, or SW experience; Windows does not randomly change data. So a plane would not get the wrong amount of fuel. What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that. It is for that reason I would never trust windows for a mission critical system. Nunc est bibendum
fat_boy wrote:
If your air traffic control system goes down, people start dying.
Wrong, resort to other means.
fat_boy wrote:
What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that.
What a strange reasoning for not choosing windows for a mission critical system, I blame the author of device drive myself. Blogless
-
fat_boy wrote:
If your air traffic control system goes down, people start dying.
Wrong, resort to other means.
fat_boy wrote:
What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that.
What a strange reasoning for not choosing windows for a mission critical system, I blame the author of device drive myself. Blogless
-
Well, looks like you're homebound. Anyway for somebody who writes 'Device drivers for Windows' you seem a bit negative towards windows :confused: Blogless -- modified at 9:39 Thursday 16th March, 2006
With very good reason. I spend a lot of time in the guts of windows, and I have seen some of the strangest behaviour. Some due to windows, some to third party software, and some due to hardware (there is a lot of variety among the architecture of laptops compared to desktops). We also find bugs in the kernel. We found two this year. One resulting in a blue screen, the other, the PC wouldnt suspend. Microsoft owned up to both of them. I think windows is an excellent OS for general use. It isnt well suited to hardware control though, its interrupt latency is too long compared to other OSs. For a mission critical system I would deffinitely look elsewhere. I might even considder NT4, at least it hasne got PnP and power management, the two real problems in XP, but even it isnt perfect. Nunc est bibendum
-
Yeah, the Ndis driver is really neat. The cards have a PPP stack on then to mimic an ISP to get windows dial up working, although over the network, it is actually GSM RF protocol etc. So, the Ndis driver stokes up the PPP stack on the card, does all the LCP, PAP, CHAP, IPCP stuff, then, tells the system the cable is connected. It then gets DHCP messages from the PC which the driver responds to with the IP address it got from IPCP. It also satisfies ARP messages with faked MAC addresses. Also, it has to do Ethernet to PPP reframing of the data packets, so, IP, PPP, UDP check sum calculation, escaping chars below 0x1F, MD5 encryption for the CHAP data, etc. The LCP/CHAP/IPCP handling code alone is 4000 lines! Yep, there is a lot of real coding there, protocols, constructing packets, real maths, and windows system knowledge. Thats what I call real software engineering! Nunc est bibendum
Have you ever had to place a work order with your employer to have the doors widened so you could move from to room? ;P All kidding aside, some of that stuff sounds absolutely fun. My Programming Library 'Even a good developer can easily write bad code in VB.NET'.--Off The Record
-
Have you ever had to place a work order with your employer to have the doors widened so you could move from to room? ;P All kidding aside, some of that stuff sounds absolutely fun. My Programming Library 'Even a good developer can easily write bad code in VB.NET'.--Off The Record
-
Yeah, the Ndis driver is really neat. The cards have a PPP stack on then to mimic an ISP to get windows dial up working, although over the network, it is actually GSM RF protocol etc. So, the Ndis driver stokes up the PPP stack on the card, does all the LCP, PAP, CHAP, IPCP stuff, then, tells the system the cable is connected. It then gets DHCP messages from the PC which the driver responds to with the IP address it got from IPCP. It also satisfies ARP messages with faked MAC addresses. Also, it has to do Ethernet to PPP reframing of the data packets, so, IP, PPP, UDP check sum calculation, escaping chars below 0x1F, MD5 encryption for the CHAP data, etc. The LCP/CHAP/IPCP handling code alone is 4000 lines! Yep, there is a lot of real coding there, protocols, constructing packets, real maths, and windows system knowledge. Thats what I call real software engineering! Nunc est bibendum
fat_boy wrote:
IP, PPP, UDP check sum calculation
Doesnt your hardware support checksum offloading ? Actually it is a pain to work with NDIS for non-ethernet type networks (for example 802.11) We wanted to scan the 802.11 medium for beacons for monitoring purposes - we cant write a standard NDIS miniport. I assume you are working directly with the vendor and writing a custom miniport with private interfaces. In any case your work sounds cool, nothing like driver development.
-
With very good reason. I spend a lot of time in the guts of windows, and I have seen some of the strangest behaviour. Some due to windows, some to third party software, and some due to hardware (there is a lot of variety among the architecture of laptops compared to desktops). We also find bugs in the kernel. We found two this year. One resulting in a blue screen, the other, the PC wouldnt suspend. Microsoft owned up to both of them. I think windows is an excellent OS for general use. It isnt well suited to hardware control though, its interrupt latency is too long compared to other OSs. For a mission critical system I would deffinitely look elsewhere. I might even considder NT4, at least it hasne got PnP and power management, the two real problems in XP, but even it isnt perfect. Nunc est bibendum
fat_boy wrote:
at least it hasne got PnP and power management, the two real problems in XP
We'll these issues would of been addressed in Vista, maybe Microsoft, should come up with a version of Windows which is Clean, that is all the unnecessary application features have been removed and maybe a streamlined kernel, just a thought Blogless
-
fat_boy wrote:
IP, PPP, UDP check sum calculation
Doesnt your hardware support checksum offloading ? Actually it is a pain to work with NDIS for non-ethernet type networks (for example 802.11) We wanted to scan the 802.11 medium for beacons for monitoring purposes - we cant write a standard NDIS miniport. I assume you are working directly with the vendor and writing a custom miniport with private interfaces. In any case your work sounds cool, nothing like driver development.
No, The device actually responds top AT commands untill ATDT*((# is sent, whereupon it switch es to PPP mode, and all it will accept is PPP packets, so no task offload there.
Vivek Rajan wrote:
802.11
We had a driver too for 802.11 for NT 4. OK, so Ndis 4 doesnt know about 802.11, but, with a custom protocol driver, custom app, and 802.11 to 802.3 reframing, it worked great.
Vivek Rajan wrote:
directly with the vendor
Yep, custom miniport driver, talks to the bus driver on the bottom edge, so read/write/control Irps, 802.3 on the top edge, with a custom IOCTL interface to get connection data to the driver, and trace data back up to the app. I am on site almost all the time, and its an on going deal. For example, there is Vista, 64 bit XP, new hardware, new speeds etc. Its a fast moving business. Nunc est bibendum