|
Indeed I was referring to desktop applications and any other application that needs to deal with the Windows API in a manner not made readily accessible from .NET. There are certain types of applications that will never be written in .NET (at least not commercially viable ones). Imaging and multimedia applications come to mind most readily. Paint.NET is cool and I use it regularly, but it's no Photoshop and the thought of creating something like Photoshop in .NET is ludicrous. The same goes for video editing apps, audio processing applications, high end games, and a lot of other things. .NET is great for gluing together components, as was classic VB, but it's no replacement for C++ and I don't really think it was intended to be. Anything that needs to integrate with the Windows shell or attain the highest performance when manipulating bytes in memory will remain most comfortably in the domain of C/C++. Period.
Yes, for web development, .NET is awesome.
|
|
|
|
|
It's because C# is horrendously inefficient. Yes, this still matters even on quad core CPU's. There are things C# is good for, but for many many things it is appallingly incompetent.
C# and C/C++ pay my bills, and the largest C# project I'm involved in is currently getting optimized by converting a chunk at a time into native C or C++.
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
modified on Monday, February 9, 2009 1:53 PM
|
|
|
|
|
" It's because C# is horrendously inefficient. Yes, this still matters even on quad core CPU's. There are things C# is good for, but for many many things it is appallingly incompetent."
That depends on what you plan to use it for...
If it's the only item you reach for in the tool box for every item, then it really is like using a hammer on every job.
There are times you would want to use C++ instead of C, so why use C# for something better suited for C++?
"Many things" it's also very good at...
I.E. Usability, Compatibility, Flexibility, and Familiarity, which are IMO more important than efficiency alone.
I'd rather have a program run without hiccups and have plenty of support available than just run fast.
|
|
|
|
|
Michael A. McCloskey wrote: It seems like Microsoft wants the rest of the world to write everything in the .NET language of their choice, but anything core to the OS or delivered with Windows is written in C++, the core stuff still being written in good ole C.
I don't see a problem with this. Most programmers are developing business (or "enterprise" if you like buzzwords) applications and for that kind of development .NET is usually a better choice. MS is mostly developing system software and C/C++ rules that field.
|
|
|
|
|
Well said Nemanja. I don't understand this tendency to say or infer: "I can't write this type of application in .NET, or can't write it completely in .NET, therefore it's useless."
Kevin
|
|
|
|
|
Michael A. McCloskey wrote: I understand they don't want us .NET developers venturing into dangerous Windows API territory
I'm sorry, but that's just a bit silly.
MS may not want .NET apps used for some purposes, where the nature of the runtime would create system stability problems... but that's just common sense. If anything MS has too often gone in the other direction, adding features to languages that do little but introduce potential for serious problems - being able to load and call into arbitrary DLLs from their scripting engines for instance.
But regardless, that has nothing to do with you as a programmer. You're not a .NET developer, forever bound to a single framework; by your own admission, you've worked extensively with at least two languages and platforms prior to picking up .NET. Therefore, you are a programmer, able to use whatever tool makes sense to get the job done. As a former VB coder, you know what sort of idiocy was involved in calling system APIs from that language, and must surely realize that P/Invoke under C# is more or less the same deal; but whereas VB development allowed you to use C++ components to handle WinAPI-heavy tasks so long as they implemented a VB-friendly API, .NET provides C++/CLI to produce seemless integration between code leveraging PSDK headers and code wishing to call it. That's a huge step forward, IMHO.
As for the use of C++ inside of Microsoft... They're in pretty much the same situation i am, but to a much, much greater degree: decades of crucial legacy code too valuable to be tossed out on a whim, severe performance requirements, and a release schedule too tight to allow for moving to a new runtime without the hope of a serious, immediate, payoff. Don't ever look for MS to lead by example on this stuff; they're a gigantic software house with little in common with most of their customers. Use the tools that work for you, and ignore the rest.
|
|
|
|
|
Very well said. I'm doing exactly what you recommend. I've learned that .NET (or at least C#) isn't the right tool for many of the types of jobs I need or want to tackle. C#/.NET (and VB.NET) are the perfect tools for the vast majority of programming tasks (IMO). If I need to whip out a utility to do something, nine times out of ten it's going to be C# and .NET and I don't foresee that situation changing as I grow more dangerous with C++ and the Windows API. This is also true for gluing databases to a front end (rich client or web) and many other types of applications.
However... anything that involves dealing with the Windows API, beyond simple P/Invoke type stuff to get a control to do a new trick, is still overly painful from C# (although yes it is a LOT better than in VB classic). I maintain that .NET is viewed as something that the "customers" use within Microsoft. Anything cool and wonderful added to the OS is typically most approachable by C/C++ programmers using the raw API, then it gets wrapped and is made accessible to the MFC crowd, then if we are very, very lucky, it gets exposed through .NET, but by this time it's typically so watered down that many of the coolest features are inaccessible, or accessible only through herculean efforts.
WPF is a huge advance in UI architecture, but it lives on an island and doesn't play well with others. They try to wrap things up nicely for us (managed DirectX, GDI+), but leave out entire branches (DirectShow, MIDI and the other multimedia API's, etc.) As a .NET developer the question is always "Can I get there from here?", with C/C++, that's never a consideration. So I'm working to add it to my toolbox. I take solace in the notion that C/C++ will remain the dominant language for interacting with the Windows API and will always get first dibs on anything new added to the OS.
|
|
|
|
|
Shog9 wrote: MS may not want .NET apps used for some purposes, where the nature of the runtime would create system stability problems... but that's just common sense.
I think all this comes from the idea that .NET is not an all-embracing Windows programming platform, but a framework MS creates for us to write applications.
This subtle difference means that MS is not forced to "eat its dog food" - VS is not written in .NET.
Think about it: COM+ is used by MS, and it works: it is part of operating system. .NET is not a platform in which MS writes MS software, so it's not complete, its roadmap is changing ever so often (think about LINQ etc.)
(You know that you cannot get position of a contol within its Window in WPF - that is possible because MS does not care: VS is not written in WPF  )
Compare it with Java. There, NetBeans is written in Java (apart from small bootstrap start procces) since it needs to run on different platforms, and so Java is a complete operating environment.
Implications are obvious: you need unamanged code to tap into graphics - and Java accelerates imaging under the hood. Just because it has to.
So... that is how it's meant to be - are are given a limited set of classes for frequently used tasks. Be happy you have it. 
|
|
|
|
|
dmitri_sps wrote: (You know that you cannot get position of a contol within its Window in WPF - that is possible because MS does not care: VS is not written in WPF )
Actually, VS 2010 is written in WPF.
And you can easily get a control's position relative to any of its parents (parent panel, window, screen - whatever you want) - OK, its a tiny bit more difficult than in Windows Forms, but that's simply because the control could be rotated/scaled/whatever.
|
|
|
|
|
dmitri_sps wrote: VS is not written in .NET.
It's not written completely in .NET but parts of it are.
dmitri_sps wrote: .NET is not a platform in which MS writes MS software
This is not true. There is lots of MS software containing lots of .NET. Again, it may not be the case that 100% of a product is in .NET. But so what?
You can tell where .NET is being used by running Process Explorer and examining the .NET processes.
One very big product that is largely written in .NET is BizTalk. But I think you will find the newer the product the more likely it is that it will contain substantial portions of .NET.
Kevin
|
|
|
|
|
dmitri_sps wrote: This subtle difference means that MS is not forced to "eat its dog food" - VS is not written in .NET.
You picked a wrong example: VS is one of few MS desktop applications that are actually moving to .NET. The reason is the same as for NetBeans - IDEs benefit from CLR features such as reflection to help developers produce their applications faster. On the other hand, MS Office is native C/C++, but the same goes for Sun's OpenOffice. Windows is written with C/C++ - so is Solaris. CLR is written with C++, Java HotSpot as well.
|
|
|
|
|
Nemanja Trifunovic wrote: You picked a wrong example: VS is one of few MS desktop applications that are actually moving to .NET.
No, this is just the correct example because you said it: it is one of few application , and it is only moving. And that's what I was saying: .NET gives you some nice sub-set of API wrappings, but it is not complete enough to write entire product in it. And that was the point of the argument.
I am sure that when VC 2010 is published, it will run on a much better version of .NET.
And I am not saying that all applications should be ported by their making companies to their own programming platforms - the costs would be prohibitive. But some complete applications and application suites utilizing the platform are definitely makes it much more functionally complete and robust.
By the way several people mentioned robustness and reachness of ASP.NET (aren't WinForms a poor second cousin to ASP.NET functionality?) - and BizTalk. And probably that also goes to show how platform benefits from its reuse. 
|
|
|
|
|
C# is targeting "top level" applications, which arent accessing the system too much. If you want to get closer to system you need C++, for device drivers or dll you than use C.
I think that is an architectual principle which Microsoft needs to seperate the volumes and API of the languages.
PS: coding C/C++ is often like reinventing the wheel (but I like it) 
Greetings from Germany
|
|
|
|
|
I think you summed it up nicely. It's sort of sad that .NET gets all the love now as far as books go. I have to use ancient books to learn the Windows API. With all the changes to Windows since Windows 95/98, you'd think someone would come out with a "Petzold" for the new generation that discusses some of the new features (Themes, Desktop Window Manager in Vista, etc.)
I'm loving C++ so far, although it's making my head hurt it many ways. C++ templates are very cool. I've run into a few surprises with generics in C# on things I thought should be possible, but aren't. I know templates and generics are two different things, but I'm excited about some of the things I can do with templates. I've grown spoiled by the intellisense in C#, which isn't quite as nice in C++, but I figure that's the price one has to pay if they want to play with knives.
|
|
|
|
|
New books are tackling the new stuff. "Thats the way the world goes..." 
I am now working on an IE extension, and so have have to stick to C++. If i wanted it to also do for the Firefox have have the problem of platform dependency. So I have to "decode" some MS-stuff to plain C. 
The MS guys are going a dangerous way with the stickyness of Windows and C#. There are other ways to make apps for instance with portable Framework as GTK or QT. That is a nice option because the MAC OS is gaining marketshare.
Greetings from Germany
|
|
|
|
|
Seemingly left out of the conversation is that on can have their cake and eat it too.
C++.NET and unmanaged C++ : Remember I J W
I don't think it's all too difficult to deal with ^ vs *, as necessary.
In some crazy parallel, that maybe only fits in my mind, this accepting C# (vs. C++) is much like the acceptability of lip-synching at allegedly live concerts. It's easier & let's one put on a fancier show somewhat easier.
But does no one else feel the warmth and nostalgia when musing over the inline assembler? You really could have it all - and you still can.
I wanna do what I wanna do when I wanna do it.
However, it's still true: money talks.
"If you can't find time to do it right the first time . . . how are you going to find time to do it again?"
|
|
|
|
|
Managed C++ does indeed allow one to play on both sides of the fence. The first book I assimilated when starting my C++ effort was Ivor Horton's Beginning C++ 2008. I diligently trodded through the book, only to wind up feeling I knew a lot about very little. Trying to grasp the basics of C++, MFC, and Managed C++ in one book is just too much. Trying to keep all the ^'s straight while learning C++ was draining. Since I already know the framework from working with C# for years, I concluded the better strategy is to:
1. Learn straight C++. I am currently doing this via the Thinking in C++ books and am on Volume 2.
2. Learn the Windows API. I have already assimilated a vintage Petzold "Programming Windows 98" and plan to assimilate a vintage copy of Jeffrey Richter's "Advanced Windows" I have in my possession.
3. Learn MFC. I've partially assimilated Jeff Prosise's "Programming Windows 95 with MFC".
4. Learn COM. I have a bookmark in Don Box's Essential COM.
5. Learn Managed C++. I assume that after having a firm foundation in the other technologies, I'll be able to more easily keep my ^'s straight.
I'm keenly aware that .NET and related technologies aren't going away, and for good reason, they are awesome. However I don't think the Windows API, COM, or MFC are going away anytime soon either. I find it interesting that to learn these technologies, I'm forced to resort to 10+ year old books. The upside is that these books are very cheap now.
I've made the observation that very few of the hugely successful applications on the desktop are written in .NET. I'm sure this is changing, but it seems to me that to attain maximum reach and to run on minimal hardware, C++ is still the way to go for most commercial desktop applications.
|
|
|
|
|
I voted in the "other" category and found that ColdFusion had only 4 votes!  
|
|
|
|
|
I developed in ColdFusion years ago for paid work purposes. It has a friendly API and it works on my Mac
When I am loaded due to Windows Coldfusion is a good choice
Cheers
Marcello Turnbull
|
|
|
|
|
C and C++ should not be together for this poll.
C used to pay my bills, but C++ never did.
|
|
|
|
|
We're using Flex for a web ui application and I'm enjoying it immensely!
|
|
|
|
|
I pay the bills with VB6, C# and SQL. I do get the occasional project in VB.Net and I would not lump that in the same category with VB6. They are 2 totally different animals. VB.Net is a lot more like C# than VB6.
And then they through VBScript in the mix?
|
|
|
|
|
Asking for a ranking of languages might offer a better picture. The only reason I included VB in my response is that it is the embedded programming language for MS SQL Server Integration and Reporting Services. So I use it, but only because I have no better choice, and it ought to appear at the bottom of my list. SQL and C# would be the top ones.
|
|
|
|
|
I agree JR. It doesn't seem consistant with the seperation of the C# and C/C++ categories in the survey.
Adding VBScript to the mix is liken to including Java and JavaScript in the same category. The languages are related in syntax but that's about it.
Interesting how you brought up SQL (Sequential Query Language). If the question was what language have you been paid to use the most over your career, my answer would have been SQL. Its not an application development language but is perhaps the most commonly used database language. Maybe it will appear in next weeks pool 
|
|
|
|
|
I noticed someone filled in RPG under their optional text.
My sympathies there. I'm glad to say I haven't had to look at RPG in well over a decade.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
