Modern GUIS and C++
-
C# is easy to learn and the Framework provides all its functions very comfortable to me. But there are some counter-arguments: C# is slow (e.g. http://www.csharphelp.com/archives2/archive458.html) like JAVA. Java and C# both compile to an interpreted language - in the past they said, this is one of the negativest features to the Basic language(s). So we came to (unmanaged) C++ - and I don't want to fight an ideologic battle.
cwp42
cwp42 wrote:
C# is slow
And for 99% of applications you will never notice the difference.
cwp42 wrote:
Java and C# both compile to an interpreted language
And this is bad why? It means (in principle at least) that you never need to recompile your application for different platforms. Seriously, if thats the 2 reasons you've chosen for going with unmanaged code you've made an error in judgement. The number of reasons I could think of for going with C# for your bog-standard GUI application would number in the tens. C+ still has many benefits, sure, but you'll find C# much easier to get to grips with, and much more what you expect GUI-wise out of the box.
-
cwp42 wrote:
C# is slow
And for 99% of applications you will never notice the difference.
cwp42 wrote:
Java and C# both compile to an interpreted language
And this is bad why? It means (in principle at least) that you never need to recompile your application for different platforms. Seriously, if thats the 2 reasons you've chosen for going with unmanaged code you've made an error in judgement. The number of reasons I could think of for going with C# for your bog-standard GUI application would number in the tens. C+ still has many benefits, sure, but you'll find C# much easier to get to grips with, and much more what you expect GUI-wise out of the box.
You are right, C# is dead slow, especially on graphics, about 10 times, it is the software GDI+ rendering. WPF is even slower, can be upto 5 times in comparison to WinForms and you will experience awful start up times and huge RAM consumption. btw, C# is compiled at runtime not interpreted but JIT doesn't help any serious performance you are probably looking for. It is so obvious and you can easily see it with IDEs that drag themselves to oblivion. I'd forget the .NET hopefuls trying to pursuade you, if you are doing any decent app that won't slam your target audience machines, then C++ is the way to go. It is harder but you do it like a man without a helping hand of a Java-like mentality somehow thinking managed is cool. Porting to C# abstraction is easy and you have plenty of articles here that will help you build your own framework (you will need one). I'd use a OpenGL and DirectX layer, just look at what MS did with new Messenger, and of course whenever it makes sense XHTML. Those "errors in judgement" hardly quantify any functional requirements, and if you have one for a fast and well-behaved GUI (imagine 10 .NET apps running at the same time, machine becomes unusable), than C# or any .NET stuff can hardly teach you anything 99% of people chase and end up with what? The same 'technology' bloat, but sure you will be more productive and perhaps .NET technology is good for an initial stage of design. Up to you really, it is easy to port between implementations but lets not kid ourselves, .NET is rendering and working as heavy as Java did back in 1998; and its performance is pathetic in comparison to anything C++ (85% yeah sure, in your dreams pedro).
-
C# is easy to learn and the Framework provides all its functions very comfortable to me. But there are some counter-arguments: C# is slow (e.g. http://www.csharphelp.com/archives2/archive458.html) like JAVA. Java and C# both compile to an interpreted language - in the past they said, this is one of the negativest features to the Basic language(s). So we came to (unmanaged) C++ - and I don't want to fight an ideologic battle.
cwp42
cwp42 wrote:
C# is easy to learn
I don't agree. It's sure much easier than c++, but not more than basic. Even for a programmer with c++ background, it takes a good amount of time to learn. Farther more what you are going to do is Visual c# .net for Windows os, which is different from plain c# and makes it times more difficult because one should also get familiar with thousands of events and their parameters and arguments plus working with controls and other os specific materials.
cwp42 wrote:
the Framework provides all its functions very comfortable to me
Sure.
cwp42 wrote:
C# is slow
Yes.
cwp42 wrote:
this[IL] is one of the negativest features to the Basic language(s)
And the best benefit at the same time. It helps to be platform independent which is critical in special works like parallel programming. It increase performance by a just in time compilation for the particular machine it runs on. It (with a common type system)helps interoperability between different languages which is a benefit in team working, etc.
cwp42 wrote:
we came to (unmanaged) C++
So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
You are right, C# is dead slow, especially on graphics, about 10 times, it is the software GDI+ rendering. WPF is even slower, can be upto 5 times in comparison to WinForms and you will experience awful start up times and huge RAM consumption. btw, C# is compiled at runtime not interpreted but JIT doesn't help any serious performance you are probably looking for. It is so obvious and you can easily see it with IDEs that drag themselves to oblivion. I'd forget the .NET hopefuls trying to pursuade you, if you are doing any decent app that won't slam your target audience machines, then C++ is the way to go. It is harder but you do it like a man without a helping hand of a Java-like mentality somehow thinking managed is cool. Porting to C# abstraction is easy and you have plenty of articles here that will help you build your own framework (you will need one). I'd use a OpenGL and DirectX layer, just look at what MS did with new Messenger, and of course whenever it makes sense XHTML. Those "errors in judgement" hardly quantify any functional requirements, and if you have one for a fast and well-behaved GUI (imagine 10 .NET apps running at the same time, machine becomes unusable), than C# or any .NET stuff can hardly teach you anything 99% of people chase and end up with what? The same 'technology' bloat, but sure you will be more productive and perhaps .NET technology is good for an initial stage of design. Up to you really, it is easy to port between implementations but lets not kid ourselves, .NET is rendering and working as heavy as Java did back in 1998; and its performance is pathetic in comparison to anything C++ (85% yeah sure, in your dreams pedro).
-
C# is easy to learn and the Framework provides all its functions very comfortable to me. But there are some counter-arguments: C# is slow (e.g. http://www.csharphelp.com/archives2/archive458.html) like JAVA. Java and C# both compile to an interpreted language - in the past they said, this is one of the negativest features to the Basic language(s). So we came to (unmanaged) C++ - and I don't want to fight an ideologic battle.
cwp42
cwp42 wrote:
C# is slow
C# is goddamn language. It can't be slow. Compiler can produce slow IL. JIT can produce slow native. .NET Framework can contain slow code. GC implementation (ok, or even concept) can be slow. But, C# itself is NOT slow.
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe -
We - a friend of mine and me - are learning C++ (especially concerning the "Microsoft World"). So we decided to code in C++ and not in C# or managed C++. But how to create (modern) GUIs? Thanks for your counsels...
Christian - cwp42
cwp42 wrote:
But how to create (modern) GUIs?
Pick a good GUI library/framework. These days I usually recommend Qt, although WTL can be an interesting choice if you are very good with C++ and don't mind sticking with VC++ and Windows.
-
We - a friend of mine and me - are learning C++ (especially concerning the "Microsoft World"). So we decided to code in C++ and not in C# or managed C++. But how to create (modern) GUIs? Thanks for your counsels...
Christian - cwp42
If you want the speed of C++ and create modern GUIs, take a look at Delphi from CodeGear. There's a free version around too so you can experiment (google Turbo Delphi Explorer, too lazy too lookup the url myself rightnow)
-
C# is easy to learn and the Framework provides all its functions very comfortable to me. But there are some counter-arguments: C# is slow (e.g. http://www.csharphelp.com/archives2/archive458.html) like JAVA. Java and C# both compile to an interpreted language - in the past they said, this is one of the negativest features to the Basic language(s). So we came to (unmanaged) C++ - and I don't want to fight an ideologic battle.
cwp42
cwp42 wrote:
C# is slow (e.g. http://www.csharphelp.com/archives2/archive458.html) like JAVA.
What IS slow is application development in C++ ...you spend all your time wrestling with the compiler, linker and the libraries. If you need to get applications out fast, .Net is the way to go. With ever-increasing processor speeds, amount of ram, multi-cores, etc., the speed advantage of compiled vs interpreted is getting less and less. .Net is easier and a lot less frustrating to learn and does most of the GUI stuff for you so you can concentrate on your program's logic.
-
cwp42 wrote:
C# is slow
C# is goddamn language. It can't be slow. Compiler can produce slow IL. JIT can produce slow native. .NET Framework can contain slow code. GC implementation (ok, or even concept) can be slow. But, C# itself is NOT slow.
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe -
C# is easy to learn and the Framework provides all its functions very comfortable to me. But there are some counter-arguments: C# is slow (e.g. http://www.csharphelp.com/archives2/archive458.html) like JAVA. Java and C# both compile to an interpreted language - in the past they said, this is one of the negativest features to the Basic language(s). So we came to (unmanaged) C++ - and I don't want to fight an ideologic battle.
cwp42
cwp42 wrote:
C# is slow
Yes, C# is slow, but the question is about GUIs. There is no such thing as a real-time GUI per se. User operations are signficantly slower than any well designed implimentation in C# or Java making interface-majority work fast enough by a significant margin. You don't get into speed differences until you start handling major 3D or mathematical operations. For instance coding a particle system with proper variable G based on altitude above the earth for high altitude motion models combined with atmospheric effects (also variable based on altitude) such as drag, and air resistance. Once you get into the higher math on large numbers of objects the speed loss of C# becomes significant. But under a GUI, I doubt even I could tell the difference and I know what to look for. A GUI is limited by the user and therefore the computer is idling more than 99% of the time waiting for user response. A computer, no matter how you slice it, is still faster than the eye-hand response time. If there is a reason other than a GUI for speed, then fine, there is a large majority who make fun of me for using C++, when I list all the features there is usually a snippy response "well if you are doing that you should expect a slow-down anyhow." or maybe even a slight give-in and an exception made. Still, there is a reason why a new version of C++ is coming, there are is a significant enough market for real-time or extremely fast operation environments where C# is just not good enough. But GUIs are definitely in the C# wins over C++ category.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
dnh wrote:
sometimes almost as slow
Visual Studio isn't slow. How can it be slow? It's only ones and zeros??? :confused:
Gary
ghle wrote:
Visual Studio isn't slow. How can it be slow? It's only ones and zeros???
Almost. VS, as every software, is bunch of electric impulses. It's lighting fast, dude. :rolleyes:
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe -
ghle wrote:
Visual Studio isn't slow. How can it be slow? It's only ones and zeros???
Almost. VS, as every software, is bunch of electric impulses. It's lighting fast, dude. :rolleyes:
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfednh wrote:
every software, is bunch of electric impulses
Not when printed on paper, deposited on a CD, hard/floppy disk, Flash Card, EProm, paper tape or punch cards.! :-O Then it's just bits of carbon dust attracted by previously deposited electrical impulses, or ink, magnetic bits, melted wires or holes. No impulse necessary. Still doesn't run (fast or slow). ;P Actually, isn't it all in our minds and biased by our frame of reference, including the perception of time? :confused:
Gary
-
cwp42 wrote:
C# is slow
Yes, C# is slow, but the question is about GUIs. There is no such thing as a real-time GUI per se. User operations are signficantly slower than any well designed implimentation in C# or Java making interface-majority work fast enough by a significant margin. You don't get into speed differences until you start handling major 3D or mathematical operations. For instance coding a particle system with proper variable G based on altitude above the earth for high altitude motion models combined with atmospheric effects (also variable based on altitude) such as drag, and air resistance. Once you get into the higher math on large numbers of objects the speed loss of C# becomes significant. But under a GUI, I doubt even I could tell the difference and I know what to look for. A GUI is limited by the user and therefore the computer is idling more than 99% of the time waiting for user response. A computer, no matter how you slice it, is still faster than the eye-hand response time. If there is a reason other than a GUI for speed, then fine, there is a large majority who make fun of me for using C++, when I list all the features there is usually a snippy response "well if you are doing that you should expect a slow-down anyhow." or maybe even a slight give-in and an exception made. Still, there is a reason why a new version of C++ is coming, there are is a significant enough market for real-time or extremely fast operation environments where C# is just not good enough. But GUIs are definitely in the C# wins over C++ category.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Amen! I'm competing my C++ app against a new whiz-bang .NET app and the customer is ready to throw out the .NET app as unusable while still desk testing. I've been running in the production environment for a while. Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app. Can't vouch for the actual code, but the customer only sees the end product. The competitor is a BIG national provider, however. We're running on a mobile device which doesn't have the GHz horsepower of PCs. MFC for the GUI worked well, with several hundred different screens in the app. All user response times should be sub-second - anything longer needs recoded! Sometimes, we just need the ability to get as close to the CPU as possible.
Gary
-
cwp42 wrote:
C# is easy to learn
I don't agree. It's sure much easier than c++, but not more than basic. Even for a programmer with c++ background, it takes a good amount of time to learn. Farther more what you are going to do is Visual c# .net for Windows os, which is different from plain c# and makes it times more difficult because one should also get familiar with thousands of events and their parameters and arguments plus working with controls and other os specific materials.
cwp42 wrote:
the Framework provides all its functions very comfortable to me
Sure.
cwp42 wrote:
C# is slow
Yes.
cwp42 wrote:
this[IL] is one of the negativest features to the Basic language(s)
And the best benefit at the same time. It helps to be platform independent which is critical in special works like parallel programming. It increase performance by a just in time compilation for the particular machine it runs on. It (with a common type system)helps interoperability between different languages which is a benefit in team working, etc.
cwp42 wrote:
we came to (unmanaged) C++
So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}Hamed Mosavi wrote:
cwp42 wrote: we came to (unmanaged) C++ So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
Odd because these are the reasons I decided to go with .net: Rarely do our customers now not already have .net installed (it was part of windows update after all), our apps are *incredibly* smaller than they were in the mfc days because we don't have to distribute so many damned .dll's and the assemblies are tiny in comparison to comparable stuff we wrote for mfc (and I do mean comparable because we ported existing apps to .net), I've found no practical difference in speed in our ported apps and in fact the .net apps are quite a lot faster because in the days of our mfc apps the hardware was much slower so the end result is the end user gets a much smaller app which is easy to download, it runs to them as fast or faster than the older mfc app they used to use. Of course you must use what works in your situation but I find my experience to be different than yours. However the fact that customers don't care what we use is absolutely true and something I wish more developers here understood. Customers only really truly care about features and hassle. They want the features but the sure thing to get them pissed off is *any* amount of hassle, however minor seeming. And this brings up the most critical point for why we switched to .net and continue to think it's the best choice: The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Modo vincis, modo vinceris.
-
You are right, C# is dead slow, especially on graphics, about 10 times, it is the software GDI+ rendering. WPF is even slower, can be upto 5 times in comparison to WinForms and you will experience awful start up times and huge RAM consumption. btw, C# is compiled at runtime not interpreted but JIT doesn't help any serious performance you are probably looking for. It is so obvious and you can easily see it with IDEs that drag themselves to oblivion. I'd forget the .NET hopefuls trying to pursuade you, if you are doing any decent app that won't slam your target audience machines, then C++ is the way to go. It is harder but you do it like a man without a helping hand of a Java-like mentality somehow thinking managed is cool. Porting to C# abstraction is easy and you have plenty of articles here that will help you build your own framework (you will need one). I'd use a OpenGL and DirectX layer, just look at what MS did with new Messenger, and of course whenever it makes sense XHTML. Those "errors in judgement" hardly quantify any functional requirements, and if you have one for a fast and well-behaved GUI (imagine 10 .NET apps running at the same time, machine becomes unusable), than C# or any .NET stuff can hardly teach you anything 99% of people chase and end up with what? The same 'technology' bloat, but sure you will be more productive and perhaps .NET technology is good for an initial stage of design. Up to you really, it is easy to port between implementations but lets not kid ourselves, .NET is rendering and working as heavy as Java did back in 1998; and its performance is pathetic in comparison to anything C++ (85% yeah sure, in your dreams pedro).
User of Users Group wrote:
imagine 10 .NET apps running at the same time, machine becomes unusable
Then you've only used .NET apps written by horrible coders. My shop has written some two dozen .NET apps that are ALL doing real-time data acquisition, signal processing, and plotting, and we regularly run 10+ of them on one machine at the same time, with absolutely no noticeable lag. It's hard work of course, but that's the nature of programming in general. .NET makes making the GUI easier; it does not relieve you of your responsibility to make the application efficient.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
Amen! I'm competing my C++ app against a new whiz-bang .NET app and the customer is ready to throw out the .NET app as unusable while still desk testing. I've been running in the production environment for a while. Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app. Can't vouch for the actual code, but the customer only sees the end product. The competitor is a BIG national provider, however. We're running on a mobile device which doesn't have the GHz horsepower of PCs. MFC for the GUI worked well, with several hundred different screens in the app. All user response times should be sub-second - anything longer needs recoded! Sometimes, we just need the ability to get as close to the CPU as possible.
Gary
ghle wrote:
Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app.
This is why for anything mathematics oriented, you would generally use native dll's written in C or C# and use PInvoke to access those functions. We do that for some of our applications and it works out beautifully. We can do some fairly sophisticated math in our .NET gui's by breaking the more complex math out into native code (I'm not talking about multiplication and addition, though - I'm talking about things like signal processing, FFTs, the sort of things that require MKL and IPP no matter WHAT development system you're using).
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
Amen! I'm competing my C++ app against a new whiz-bang .NET app and the customer is ready to throw out the .NET app as unusable while still desk testing. I've been running in the production environment for a while. Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app. Can't vouch for the actual code, but the customer only sees the end product. The competitor is a BIG national provider, however. We're running on a mobile device which doesn't have the GHz horsepower of PCs. MFC for the GUI worked well, with several hundred different screens in the app. All user response times should be sub-second - anything longer needs recoded! Sometimes, we just need the ability to get as close to the CPU as possible.
Gary
ghle wrote:
All user response times should be sub-second - anything longer needs recoded!
very true, but even java should be capable of writing a GUI with that as the only limitation. C# will beat Java hands down, and C++, although faster, will sometimes generate slower code for GUIs depending on the API chosen. The rest of the results are completely in the air depending on the programmer. Bad code can be written by anyone, including and experience programmer when he steps out of his speciality. Life in the real-time world rarely has UIs, but I have done enough of them to use a large variety of environments including C#, though I have delivered no C# GUIs to any customer yet. As long as you don't do something obviously detrimental to speed, and the programmer is competent (those two kind of go hand in hand, but every programmer, even experienced ones sometimes make silly mistakes), you should be able to get a GUI to subsecond response on any modern language. The back-end stuff is where the details are. And depending on the needs you can call a power-number-mashing DLL from C# (or Java as one of our team has done). So the real queston on which primary language to use is a very difficult one to answer, partly depends on the skill sets you have, and also depends on the over all goals of the project and the company. If you want everything uniform, do you stick with C++ with C++ GUI operations? do you hybridize your operatons with core functionality in C++ called from a C# front-end? That is where you start aligning pros and cons to each and the significant cost associated in man-hours. C# GUI's are cheap in labor costs, but learning curves for retraining for the larger core sets would be more significant, and not always worthwhile to the run-tme operations speed. Hybrdizing is a cheap alternative, but cheap GUIs up front, hard-won DLLs on the back. C++ all the way around may be desireable because of one language, one training set, one, one, one. Not a bad idea in some situations. The hard decision is what is good for your project or your company, the impossible decision is what one choice is good for everyone. There is no answer for EVERYONE, there is only the answer for each person, each group, each company.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Hamed Mosavi wrote:
cwp42 wrote: we came to (unmanaged) C++ So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
Odd because these are the reasons I decided to go with .net: Rarely do our customers now not already have .net installed (it was part of windows update after all), our apps are *incredibly* smaller than they were in the mfc days because we don't have to distribute so many damned .dll's and the assemblies are tiny in comparison to comparable stuff we wrote for mfc (and I do mean comparable because we ported existing apps to .net), I've found no practical difference in speed in our ported apps and in fact the .net apps are quite a lot faster because in the days of our mfc apps the hardware was much slower so the end result is the end user gets a much smaller app which is easy to download, it runs to them as fast or faster than the older mfc app they used to use. Of course you must use what works in your situation but I find my experience to be different than yours. However the fact that customers don't care what we use is absolutely true and something I wish more developers here understood. Customers only really truly care about features and hassle. They want the features but the sure thing to get them pissed off is *any* amount of hassle, however minor seeming. And this brings up the most critical point for why we switched to .net and continue to think it's the best choice: The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Modo vincis, modo vinceris.
John Cardinal wrote:
The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Here's our difference. My project are small enough (I don't remember any project more than 23,000 LOC) that I code alone or with one more programmer. We rarely need to use third party libraries( except for UltimateToolBox ). I don't remember to be using dlls more than in three or four projects and I really like MFC. All in all,you are absolutely right. The problem I encountered in .Net, actually, is lack of knowledge:sigh: I was lazy or busy enough or had not enough confidence to start a real project in C#. For example I know what exactly is happening when I pass a pointer to an object as a parameter of a function, but in .Net I don't know which method is safe or has best performance. It took years to learn these in C++. I think I need to read a really good, in debt book about it, and I think it'll take a long time, I don't have enough reasons to go there yet, because I'm not sure what benefits I get in return. By the way, how long did it take to learn c# for you?
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
John Cardinal wrote:
The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Here's our difference. My project are small enough (I don't remember any project more than 23,000 LOC) that I code alone or with one more programmer. We rarely need to use third party libraries( except for UltimateToolBox ). I don't remember to be using dlls more than in three or four projects and I really like MFC. All in all,you are absolutely right. The problem I encountered in .Net, actually, is lack of knowledge:sigh: I was lazy or busy enough or had not enough confidence to start a real project in C#. For example I know what exactly is happening when I pass a pointer to an object as a parameter of a function, but in .Net I don't know which method is safe or has best performance. It took years to learn these in C++. I think I need to read a really good, in debt book about it, and I think it'll take a long time, I don't have enough reasons to go there yet, because I'm not sure what benefits I get in return. By the way, how long did it take to learn c# for you?
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}Hamed Mosavi wrote:
We rarely need to use third party libraries
Yeah that's a *major* difference, we used to have *many* third party libraries for everything from reporting to encryption. Many of those were no longer required in .net because they were built in, however we probably have even more third party libraries now with all the new features, but they are never an issue like they used to be.
Hamed Mosavi wrote:
It took years to learn these in C++.
I know what you mean, but once you get into .net you will realize how much of that knowledge is just not relevant or required. There is no where *near* the learning curve, particularly if you are an experienced c++ developer. I continually found my barrier was thinking "it can't just be that simple" when learning c# and overthinking the whole process. I found this book invaluable when learning c#: A programmers introduction to c#[^] It's clean, simple and gets to the point without replicating a lot of stuff you already know. The biggest thing to learn in c# isn't really the language itself, you can pick that up in a couple of days if you're an experienced c++ programmer, it's the .net api which is huge, however that's the good thing about it since it contains so much stuff you never need to write yourself. My productivity shot up with .net compared to c++ / mfc. It's not at all an exageration to say that I can develop an equivalent project in quarter or less time (my gut feeling is a tenth) than it used to take with MFC / C++. That's from the original idea on paper to delivered into end users hands debugged and stable. It took me about a week to learn enough to start writing winform apps in c# and the rest I pick up as I need it. Asp.net was actually the hardest thing to learn at first and even that was a dream compared to classic asp which I found a horrible nightmare of complexity. Whether it's a good fit for what you do or not you'll only know if you take the time to make a project of some kind with it, just something for fun. I find learning out of a book pretty much useless for retention, it's great for an overview to know what is out there, but nothing substitutes for jumping in and making an a
-
ghle wrote:
All user response times should be sub-second - anything longer needs recoded!
very true, but even java should be capable of writing a GUI with that as the only limitation. C# will beat Java hands down, and C++, although faster, will sometimes generate slower code for GUIs depending on the API chosen. The rest of the results are completely in the air depending on the programmer. Bad code can be written by anyone, including and experience programmer when he steps out of his speciality. Life in the real-time world rarely has UIs, but I have done enough of them to use a large variety of environments including C#, though I have delivered no C# GUIs to any customer yet. As long as you don't do something obviously detrimental to speed, and the programmer is competent (those two kind of go hand in hand, but every programmer, even experienced ones sometimes make silly mistakes), you should be able to get a GUI to subsecond response on any modern language. The back-end stuff is where the details are. And depending on the needs you can call a power-number-mashing DLL from C# (or Java as one of our team has done). So the real queston on which primary language to use is a very difficult one to answer, partly depends on the skill sets you have, and also depends on the over all goals of the project and the company. If you want everything uniform, do you stick with C++ with C++ GUI operations? do you hybridize your operatons with core functionality in C++ called from a C# front-end? That is where you start aligning pros and cons to each and the significant cost associated in man-hours. C# GUI's are cheap in labor costs, but learning curves for retraining for the larger core sets would be more significant, and not always worthwhile to the run-tme operations speed. Hybrdizing is a cheap alternative, but cheap GUIs up front, hard-won DLLs on the back. C++ all the way around may be desireable because of one language, one training set, one, one, one. Not a bad idea in some situations. The hard decision is what is good for your project or your company, the impossible decision is what one choice is good for everyone. There is no answer for EVERYONE, there is only the answer for each person, each group, each company.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
very true, but even java should be capable of writing a GUI with that as the only limitation.
Which reminds me of one more limitation. Writing code for handheld devices, I don't have the plethora of languages available for the PC. Starting out in Windows CE, it was VC++ only, then Visual Basic was added, then later upgrade to WinCE OS and VB support went away. Then VB was back. Finally, MS ported over development from separate IDE to VS 2005 which opens the doors to other languages. (Personal feeling was it was done to foist C# and .NET upon us.) But still supporting older stuff, VC++ & VB are the only available languages to us. Monopolies suck! Anyone know of alternatives to MS for Mobile development for WinCE? :mad:
Gary