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
Marc Clifton wrote:
It's a tool, not a religion.
Couldn't agree more.
Marc Clifton wrote:
Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest.
I completely agree on that one as well. But ... why can't I have the cake and eat it too? Why can't MS continue to improve their native tools as well? It sure isn't for lack of resources - indeed it would cost them very little to get something like the .NET framework (the classes of it) running in native C++. /Simon This is not a signature.
-
Michael P Butler wrote:
but why do you prefer it?
I guess the short answer is flexibility and control. Sure: for ultimate flexibility and control you should always use assembler :-D There's always a trade-off between flexibility + control on the one hand and ease-of-use on the other hand. But come to think of it, what I don't like about .NET (and Java) is not that it's a VM (after all, the Win32 API is kind-of a VM too, it's only the kernel that isn't). What I don't like is the garbage collection. It's the flexibility and control of pointers that make me reluctant to use .NET. /Simon This is not a signature.
Agreed, it does take some getting used too. Have had some nasty problems caused by my ignorance of the GC when I first stare developing in .NET. You can of course use garbage collection in C++ if you wish.. It's not like controlling memory allocation is a big problem in C++ if you use smart pointers and whatnot. 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. 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
-
Reasons to use .NET
- Increased security (both in applications having less chance to cause havoc, and malicous users having less chance of effecting buffer overflow attacks) since it's built into the framework
- reduced bugs and increased reliability through a managed environment
- higher productivity through a better architected language, better tools (reflection allows better intellisense, debugging etc), and a single Base Class Library for all languages
- Inter-language operabililty and a common programming model
- A wicked-cool component model
- No more DLL hell
- XCopy deployment (sometimes)
- The inevitable march towards XAML and the convergence of Web and desktop development
That's off the top of my head. I'm sure I've missed a couple. However, there's no valid argument (yet) to say everyone should move from Win32 to .NET. .NET simply isn't suitable for all tasks (OS development, drivers, high-perf applications). As always, choose the right tool for the job. cheers, Chris Maunder
CodeProject.com : C++ MVP
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.
-
I wrote:
Why doesn't Microsoft do that? [Why don't they create a really good framework in native code?]
Ryan Binns wrote:
What language would you do it for? Whichever one they chose, they would have developers in the other languages screaming for blood. The way they have done it, they make the framework available to everyone.
Well:
Ryan Binns wrote:
They know that there are classes of applications that will see no (or little) benefit from moving to a .NET platform.
What languages are those classes of applications written in? My guess is 98% C++ (and 80% of those use MFC). Ergo: the language would be C++. Why not give us something like MFC but 1000% better. I'd say all other languages are much easier to replace with the .NET framework. But being a C++ developer I don't know for sure (oh I'm so humble :rolleyes:). /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
-
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
Kevin McFarlane wrote:
But why do so many C++ developers tend to think that everything should be done in C++?
Oh, that's an old one. If you have a hammer, everything looks like a nail. And if you have a hammer that can accomplish anything then you are very tempted to use it at everything, even though there might be better tools for it. /Simon This is not a signature.
-
Agreed, it does take some getting used too. Have had some nasty problems caused by my ignorance of the GC when I first stare developing in .NET. You can of course use garbage collection in C++ if you wish.. It's not like controlling memory allocation is a big problem in C++ if you use smart pointers and whatnot. 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. 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
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.
-
Marc Clifton wrote:
It's a tool, not a religion.
Couldn't agree more.
Marc Clifton wrote:
Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest.
I completely agree on that one as well. But ... why can't I have the cake and eat it too? Why can't MS continue to improve their native tools as well? It sure isn't for lack of resources - indeed it would cost them very little to get something like the .NET framework (the classes of it) running in native C++. /Simon This is not a signature.
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
-
norm.net wrote:
Wow! There goes your pay cheque
For mission critical I would never considder windows, would you? Nunc est bibendum
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.
-
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)
