Modern GUIS and C++
-
Your post is too subtle and toned down to be Kyle, so i'll assume you are a newbie. With that said, please go post the question in the correct programming forum. Although i don't even recommend you ask the question at all. Google and search thru CP articles first, then ask a more specific question if you get stuck and Googling for the problem doesn't seem to help. Roswell
"Angelinos -- excuse me. There will be civility today."
Antonio VillaRaigosa
City Mayor, Los Angeles, CASorry. Your're right: I'm a newbe. What I'm looking for is a general decision: what is the right way, a future-proof way, for me designing GUIs for C++ written software. There are lot of frameworks...some opinions that MFC is getting old...but there are new (commercial) versions of MFC 2007... There are GDI+ wrapper...the WinFX...WPF... I'm interested on how would a C++ guru decide.
cwp42
-
You will realize sooner or later that you made an unfortunate decision. If you want modern GUI's .NET is really the path you should follow.
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
-
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 like JAVA.
Slow ? no. slower than C/C++, but you could make very crap C/C++ code which could run mush slower than a well written C#/Java code. all depends if you need real time preformances or not. for most management applications, C#/Java speeds are more than enough.
cwp42 wrote:
Java and C# both compile to an interpreted language
then what ? i can't understand in what this is a negative feature, as it is finally compiled to the target assembly at the first execution...!! it seems that you just looked at the negative parts... and know that i am a C++ addict (that is to say that i don't defend C# as if it was the only language i'd know)
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
-
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)