i was never a fan of .net. .net is very slow compared to c++ and i dont think .net will ever replace c++, even in companies.
i was never a fan of .net. .net is very slow compared to c++ and i dont think .net will ever replace c++, even in companies.
i actually do care about portability. the only problem is i dont like 3rd party libraries that much. the day the standard libraries get grahics, sound, and networking libraries i will become a portable programmer.
So until then you won't use graphics, sound, or networking?
Oh well... I don't think this "C# is slow" mantra will ever end. It's been discussed so many times of these forums and it hasn't yet.Originally Posted by lruc
Just do yourself a favor... don't... buy... the... C#... is... slow... argument. You won't regret it. If that's your problem with C#, then you clearly need to study it better.
uh? You just don't like them because you don't know them, or you don't like them for a specific reason you are not sharing with us. I'm most curious as to what the collective of 3rd party libraries has that makes you not liking it...Originally Posted by lruc
Since the answer is probably going to frustrate me, I suggest instead your reevaluate your position and consider that the strength of C++ lies exactly on its 3rd party libraries. The language itself, plus Standard Library and STL is pretty much dull and boring... unless you are a 3rd party library developer. Which obviously you are not.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
c# being slow is something i have just heard many times and you might be right, but i really dont know. also, its not so much that i dont like 3rd party libraries so much as i prefer the api's instead. was that frustrating???
The slowness of C# compiled code isnt a property of the language itself, but a consequence of its implimentation. The first C/C++ compilers werent all that fast compared to assembly, bu tthye improve over time. Im sure of C# recieves a lot of attention it will improve over time as well. Its really more of a transitional language though, meant to help stear VB users towards C/C++ without the steep learnign curve of a comlete switch. In microsofts own words C/C++ are the language of choice for performance and raw computing power. They also stopped supporting FoxPro so both of the foxpro users are looking for a replacement language.
C# is just Microsoft's own attempt to monopolize the programming market, if you ask me.
They don't own C/C++, but they can have a lot of say in C#.
I doubt C# will get faster due to its nature. It's interpreted and compiled. Maybe you could say dynamically recompiled.
But the fact is that it is not native code and therefore will always run slower than C/C++, regardless of what Microsoft says.
Well, regardless what you good people say, I say C# is not slower than C++ for the type of applications it targets. And when it is, it's almost always negligible.
For all that matters, my beloved C++/wxWidgets is at least one magnitude slower than C# on most windows related tasks. And yet... you guessed it... nobody seems to care. I don't hear a ruckus about it, do any of you? (and still is a quiet promising way of programming for Windows... or no one uses CodeBlocks anymore... because it's slow?)
It becomes an issue if the 0.1 seconds it takes to load a 10,000 item list control after you click a button is unacceptable and what you want is 0.08 seconds. But then... well, lets just say the bottleneck is almost always on the code and rarely on the language.
If you want to squeeze every bit of performance of your GUI application, the best option - and the one that brings sure results - is changing programmers, not programming languages.
Last edited by Mario F.; 07-01-2008 at 10:32 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
This obviously is incorrect since Microsoft just updated the entire MFC framework as of MSVS 2008. Microsoft is going to publish whatever the devs will buy and they found a lot of devs wanted an update to MFC so that's exactly what they gave them....I wouldn't put much effort in learning MFC at this point since Microsoft clearly wants to get rid of it as soon as it can.
But it is true that even Microsoft clearly states that they have no intention of replacing C/C++ via C# or any other language out there. They recommend C/C++ over all others if you need raw power. Fact is most applications do not and C# will suffice.
In my own experience C# apps do run a bit slower than MFC apps. Whether this is because I suck at C# or not is definitely up for debate. Overall I find it takes more time for common dialogs to come up and for common controls to do their 'thing' whatever that may be. It feels as if .NET takes a very long time to load 'something' when you are using the default controls and dialogs but I've never discovered what it is or read anything as to why this may occur. Perhaps this is more of a problem with .NET than C# since C# seems to do quite well for most in XNA. So perhaps the more correct answer is that .NET is slower than the CRT which I believe we all would agree on.
C# is a very nice language though and .NET supports just about anything you would want to do and more. I honestly cannot make a recommendation between C# and MFC C++ apps. For me the final decision is how easily will the tool interface with existing tools? Another big question is what are the current crop of tools written in and if I change that do I unnecessarily increase the maintenance task? Most of these decisions are made far above my pay grade but that is some of the thought process they have told us they use to determine which language to use for tools. Is it easier to teach new devs MFC or C#? If most the tools are in C# using MFC may not be a wise choice and vice versa. For now most of our GUI tools are written in C#. I will say this has made it difficult at times to interface with existing code for testing and so forth since managed and unmanaged code do not play well together. If somehow the interop between C# and C++ could be eased a bit I think it would be even more widely used. For now it usually comes down to making a COM component that acts as a wrapper or writing a C style wrapper that wraps access to the C++ class. The wrapper then can be called from C# since C calls are not using this call and the wrapper then calls the C++ functions.
Last edited by VirtualAce; 07-01-2008 at 10:01 PM.
Your choice of framework / API shoud depend on where you want to go with programming.
The software houses I have worked for have only used WIN32 and MFC. (for C/C++ GUIs)
None used any third party API commercially.
You may dislike MFC, but it is not going anywhere quickly. We are simply not porting to .NET (nor to Vista).
If you plan a programming career, experience with the frameworks / APIs used commercially is more important than which one YOU prefer.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
Didn't know about this. Just took a quick look. It however seems to me mostly a cosmetic getting up-to-date effort, Bubba. Mostly new controls. Although, the new shell management classes and TR1 support seem no doubt a great addition. They also say they will keep improving it...
Well glad I'm wrong on this one. It's been my reasoning that one of Microsoft wishes behind .Net is exactly to cut down on C++ development on windows on account of all security issues that plague the operating system. MFC would, on this case, be a priority target. The pushing of C#, no framework support for C++, an outdated MFC, a .Net based OS, all contributed to this general feeling I had; basically that Microsoft is winking everyone into .net development and to drop C++/MFC/Win32.
I'm still somewhat unsure. I wonder how much of that upgrade wasn't the result of pressure from major customers and public in general... and, at the same time, Microsoft realization C# didn't really replace C++ as much as they wished.
Last edited by Mario F.; 07-02-2008 at 06:56 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
C/C++ are MS's bread and butter, they will not 'deprecate' it in our lifetime. MFC and .NET are fine for most applications, but new and innovative and particularly science and engineering related development requires more than just out of the box classes. This is one of the reasons I was appalled to find no support for inline assembly in x64, since the very market that is most likely to use x64 is the same market that is most likely to use inline assembly (engineers).
You're not alone in that you are appalled to see no inline asm support in x86.
It has been one of the reasons I've been reluctant to embrace x64. Although, nowadays, I'm less likely to rely on asm. Still, it's a very big shortcoming of ms, if you ask me.