Which is faster...
-
Define faster. Do you mean faster to execute or faster to develop? Faster to execute is most likely direct Windows API but with optimization in the compiler you won't really notice a difference. If you mean in speed of developing, well, I would say MFC, but it really depends on how well you know MFC and how well you know the windows API. -- Rocky Dean Pulley
-
In many cases, the MFC is a thin layer above the Win32 API. Therefore, in those cases the coding directly to the API will be slightly faster. However, it's doubtful that it would be any thing significant and is outweighed by the ease of use of the MFC over the Win32 API. Cheers, Tom Archer - Archer Consulting Group
"Eat your brussel sprouts, Junior. There are starving Chinese children American programmers that would kill for that food!" -
Define faster. Do you mean faster to execute or faster to develop? Faster to execute is most likely direct Windows API but with optimization in the compiler you won't really notice a difference. If you mean in speed of developing, well, I would say MFC, but it really depends on how well you know MFC and how well you know the windows API. -- Rocky Dean Pulley
-
I actually came from VB and I went to C++ hoping that I would port the code from VB to C++ and it would execute faster. So, I'm more familiar of the Windows APIs than these MFC Classes.
User Interface Code is rarely time critical. There are two major issues to consider: - Repaint Speed Are display changes "Immeditely"? Slow form building is what makes (or at least made early) VB applications looking sluggish. There's no notable difference between Win32 API and MFC, and it is usually no problem (If it is looks slow you do something wrong :) ) - Flicker rarely a speed issue, but looks "amateurish". This is a question of how it's programmed, not how fast it runs. - User Action Response time To handle a user action (e.g. a click on a button), you have about 100..200 ms to handle the message before the user notices a delay. This is more than enough for most actions. Beyond that, "faster" is bound to the old rule: (all sing along!) "90% of the time is spent in 10% of the code". I would update this rule to "95% of the time spent is caused by 5% of the code" (Limiting factors are nowadays less the CPU, but memory throughput, diska access, etc.) NeverFall wrote: I actually came from VB and I went to C++ hoping that I would port the code from VB to C++ and it would execute faster A straight 1:1 port will not make a difference for many applications. It all depends on what they do. C++ is not the "Porsche Edition of the the VB go-cart", but a fleet of specialized vehicles which can do the same task much faster if they are used correctly
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen -
I actually came from VB and I went to C++ hoping that I would port the code from VB to C++ and it would execute faster. So, I'm more familiar of the Windows APIs than these MFC Classes.
In comparison to VB you don't need to care if Win32 or MFC is faster... They are all MUCH faster than VB. Don't try it, just do it! ;-)