.Net, WTL and MFC/ATL
-
MFC has been around for many years, ATL is getting more mature to be used. However, VB has catch-up so fast, previous advantages with VC in modern programming has became very little. Comparing VB to VC (from the eyes of marketing manager), if you are talking about memory management, code size, functionality or speed, the differences are simply too small. VB is MORE productive and powerful compare to VC in developing enterprise level application package, like it or not. Worst of all, VC often need to go through at least 2 service packs to go steady. WTL is simply a toy for hardcore C++ supporter, I seriously doubt the productivity of WTL in modern multi-tier application. I think it will suffer the same problem like AFX at the end. At the meantime, I believe MFC/ATL really need to be update to a true "Enterprise" level application tools like VB.
-
I think that it's obvius that C++ is not UI design language, and VB is not for app core development. That's all. Just use each language for that things it is mostly suitable. :suss:
Absolutely. C# or VB or any other rapid UI builder front end, unless you need doc/view, or are maintaining compatibility with existing MFC stuff. C++ for the business logic with a bit of judicious profiling to performance tune the C++ (remember the 80%/20% rule)
-
I think that it's obvius that C++ is not UI design language, and VB is not for app core development. That's all. Just use each language for that things it is mostly suitable. :suss:
please, show me one place where VB meets or exceeds C++ as a "UI design language". C++ is perfect for UI design. start with a generic window class that knows something about mouse clicks and clipping; from that, create a generic button class that knows something about being pushed and sending the appropriate message when a push occurs; from that, create a button with text and a button with an image and a button with both text and an image, a button that doesn't have a 3D look and a button that does, a button that stays down when you press it and a button that is transparent. want all of your buttons to make a noise when they're pressed? change the "OnPressed" code in the base class to make a noise. all of the positioning and button behavior is in the base "button" class, but the derived classes can draw themselves however they want via virtual functions. and luckily, MS has already done most of this work in MFC. and even better, you can do all of this without having to screw around with ActiveX or COM - hooray! and, you can do it without distributing the VB runtimes - hooray! -c ---------------------- www.smalleranimals.com
-
put that 5% slower in a loop repeated 10,000 times and guess what: your app is too slow. i don't have all day to sit around while your app runs; some of us actually have to get work done. :) -c
Well put Chris, I also like to add: 1. To distribute put all the DLLs, EXEs together and get a 39mb redistributable file. 2. Copy it to your target machine. 3. when the installation files find some more dlls and go to step 1. do this until intallation works (if it every does). No I'd rather copy a small executable, say about 930kb and run the app with no problems at all, and I too don't have all day to mess about with VB and its versioning problems :(
-
please, show me one place where VB meets or exceeds C++ as a "UI design language". C++ is perfect for UI design. start with a generic window class that knows something about mouse clicks and clipping; from that, create a generic button class that knows something about being pushed and sending the appropriate message when a push occurs; from that, create a button with text and a button with an image and a button with both text and an image, a button that doesn't have a 3D look and a button that does, a button that stays down when you press it and a button that is transparent. want all of your buttons to make a noise when they're pressed? change the "OnPressed" code in the base class to make a noise. all of the positioning and button behavior is in the base "button" class, but the derived classes can draw themselves however they want via virtual functions. and luckily, MS has already done most of this work in MFC. and even better, you can do all of this without having to screw around with ActiveX or COM - hooray! and, you can do it without distributing the VB runtimes - hooray! -c ---------------------- www.smalleranimals.com
C++ is perfect for UI design, but MFC isn't RAD in DevStudio. There is a company that does a product that turns DevStudio into a RAD environment using addins and a class library that inherits from MFC, but their name escapes me at the moment. VB is far from perfect, but it is quick to get a simple UI up and running. We use it as the front end for one of our products, simple COM components and some internal tools. There are rumblings to port the front end to MFC though for performance reasons and consistency with other products. I used Borland Delphi and C++ Builder for a couple of years and they blow MFC and VB away completely, though they don't have a doc/view architecture. It's just a shame one never became the standard for RAD, such is the power of DevStudio as a complete solution.
-
C++ is perfect for UI design, but MFC isn't RAD in DevStudio. There is a company that does a product that turns DevStudio into a RAD environment using addins and a class library that inherits from MFC, but their name escapes me at the moment. VB is far from perfect, but it is quick to get a simple UI up and running. We use it as the front end for one of our products, simple COM components and some internal tools. There are rumblings to port the front end to MFC though for performance reasons and consistency with other products. I used Borland Delphi and C++ Builder for a couple of years and they blow MFC and VB away completely, though they don't have a doc/view architecture. It's just a shame one never became the standard for RAD, such is the power of DevStudio as a complete solution.
Here is the company that makes the DevStudio add-in called RadVC. It lets a VC++ developer work in a VB-like RAD environment. http://www.capitolsoft.com
-
put that 5% slower in a loop repeated 10,000 times and guess what: your app is too slow. i don't have all day to sit around while your app runs; some of us actually have to get work done. :) -c
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. As to the distribution sizes (See Norm's comment), VB7 won't have this problem. (stirring the flames :) ) cheers, Chris Maunder
-
Well put Chris, I also like to add: 1. To distribute put all the DLLs, EXEs together and get a 39mb redistributable file. 2. Copy it to your target machine. 3. when the installation files find some more dlls and go to step 1. do this until intallation works (if it every does). No I'd rather copy a small executable, say about 930kb and run the app with no problems at all, and I too don't have all day to mess about with VB and its versioning problems :(
I think you'll find VB7 finally gets over this. cheers, Chris Maunder
-
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. As to the distribution sizes (See Norm's comment), VB7 won't have this problem. (stirring the flames :) ) cheers, Chris Maunder
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. -- yes :) but as the time to process goes up, that 5% gets bigger and bigger and bigger. and eventually, that 5% may just be too long, for some applications. personally, i like to squeeze every nanosecond out of my apps as possible. -c
-
Sounds like a dero to me. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. -- yes :) but as the time to process goes up, that 5% gets bigger and bigger and bigger. and eventually, that 5% may just be too long, for some applications. personally, i like to squeeze every nanosecond out of my apps as possible. -c
I also do agree with you. Mainly if you have to write scientific applications. Not to mention real time apps.
-
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. -- yes :) but as the time to process goes up, that 5% gets bigger and bigger and bigger. and eventually, that 5% may just be too long, for some applications. personally, i like to squeeze every nanosecond out of my apps as possible. -c
I also do agree with you. Mainly if you have to write scientific applications. Not to mention real time apps
-
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. -- yes :) but as the time to process goes up, that 5% gets bigger and bigger and bigger. and eventually, that 5% may just be too long, for some applications. personally, i like to squeeze every nanosecond out of my apps as possible. -c
I also do agree with you. Mainly if you have to write scientific applications. Not to mention real time apps
-
MFC has been around for many years, ATL is getting more mature to be used. However, VB has catch-up so fast, previous advantages with VC in modern programming has became very little. Comparing VB to VC (from the eyes of marketing manager), if you are talking about memory management, code size, functionality or speed, the differences are simply too small. VB is MORE productive and powerful compare to VC in developing enterprise level application package, like it or not. Worst of all, VC often need to go through at least 2 service packs to go steady. WTL is simply a toy for hardcore C++ supporter, I seriously doubt the productivity of WTL in modern multi-tier application. I think it will suffer the same problem like AFX at the end. At the meantime, I believe MFC/ATL really need to be update to a true "Enterprise" level application tools like VB.
While indeed, VB has become more powerful, it still isn't a completley general purpose language. VB will only work in "managed" .NET mode. That means there are entire classes of applications which are not appropriate for .NET. You won't be seeing Symantec making their next virus scanner in .NET, nor will you see the next distributed.net client or seti@home client running in .NET. You won't see Disk defragmenters written in .NET. "Modern multi-tier applications" are only a subset of what people develop today.
-
A tight 10,000 iteration loop that has internals that are 5% slower than the high performance C++ version is still only going to be 5% slower overall. -- yes :) but as the time to process goes up, that 5% gets bigger and bigger and bigger. and eventually, that 5% may just be too long, for some applications. personally, i like to squeeze every nanosecond out of my apps as possible. -c
I used to agree with you. I love c++ very dearly - the amount of hours of learning I have put in and the joy that I have got from those hours is great. (I would say the same for COM) But... But, alas and alack, other people do not have this love (which I find sad and in some ways disappointing) and trying to teach other people how to take over my work as I prepare to leave in a few months is somewhat difficult. Oh, you scoff, you code must be hard to read; obscure; badly written. No, no I don't think so. It's hard because I have used STL. It's hard because I have used c++ idioms. It's hard because I have used ATL. It's hard because I have used the BEST features of the language. It's hard because I used COM. There is a place for all these things; but that place is a very small place. It's some temple where miracles DO HAPPEN, but through blood, sweat and a lot of tears, and most people just don't want that complication in their lives. It makes me sad in some respect, but what we should be doing is choosing the simplist path, as it allows you to approach greater problems. (Now, I'm not saying that your typical VB programmer is capable of this; chances are they are a lazy two-bit swine, who is picking up a shit load of cash for a bag of beans; but...) The simple truth is that most software should be been like most consumer products; as throw away. When the technology becomes stable; well that's when all those hard fought and won battles of software engineering can come into play (or in rare cases!!). Hows this for stirring the flames? Unfortunantly, I'm coming to believe its true though. Have fun, Paul Westcott.
-
I used to agree with you. I love c++ very dearly - the amount of hours of learning I have put in and the joy that I have got from those hours is great. (I would say the same for COM) But... But, alas and alack, other people do not have this love (which I find sad and in some ways disappointing) and trying to teach other people how to take over my work as I prepare to leave in a few months is somewhat difficult. Oh, you scoff, you code must be hard to read; obscure; badly written. No, no I don't think so. It's hard because I have used STL. It's hard because I have used c++ idioms. It's hard because I have used ATL. It's hard because I have used the BEST features of the language. It's hard because I used COM. There is a place for all these things; but that place is a very small place. It's some temple where miracles DO HAPPEN, but through blood, sweat and a lot of tears, and most people just don't want that complication in their lives. It makes me sad in some respect, but what we should be doing is choosing the simplist path, as it allows you to approach greater problems. (Now, I'm not saying that your typical VB programmer is capable of this; chances are they are a lazy two-bit swine, who is picking up a shit load of cash for a bag of beans; but...) The simple truth is that most software should be been like most consumer products; as throw away. When the technology becomes stable; well that's when all those hard fought and won battles of software engineering can come into play (or in rare cases!!). Hows this for stirring the flames? Unfortunantly, I'm coming to believe its true though. Have fun, Paul Westcott.
In my case, the simple truth is that it's hard because i choose to work on hard problems. The programming part is not hard and VB would not make it easier; Delphi would not make it easier. The only thing that would make the problem easier is if i changed the problem - but the problem is the interesting part. I feel sorry for people who are only interested in the end product. And to me, VB and other RAD tools represent these kind of people. [cue dramatic music and fade out...] :) -c ---- www.smalleranimals.com
-
Your obviously strugglint with Windows Programming in General and using Visual Basic for 'easy' alternative. Both languages have the Pros and Cons, productivity is not an attribute which both languages can be measured. Please get your fact correct before you come in flaming...
-
I used to agree with you. I love c++ very dearly - the amount of hours of learning I have put in and the joy that I have got from those hours is great. (I would say the same for COM) But... But, alas and alack, other people do not have this love (which I find sad and in some ways disappointing) and trying to teach other people how to take over my work as I prepare to leave in a few months is somewhat difficult. Oh, you scoff, you code must be hard to read; obscure; badly written. No, no I don't think so. It's hard because I have used STL. It's hard because I have used c++ idioms. It's hard because I have used ATL. It's hard because I have used the BEST features of the language. It's hard because I used COM. There is a place for all these things; but that place is a very small place. It's some temple where miracles DO HAPPEN, but through blood, sweat and a lot of tears, and most people just don't want that complication in their lives. It makes me sad in some respect, but what we should be doing is choosing the simplist path, as it allows you to approach greater problems. (Now, I'm not saying that your typical VB programmer is capable of this; chances are they are a lazy two-bit swine, who is picking up a shit load of cash for a bag of beans; but...) The simple truth is that most software should be been like most consumer products; as throw away. When the technology becomes stable; well that's when all those hard fought and won battles of software engineering can come into play (or in rare cases!!). Hows this for stirring the flames? Unfortunantly, I'm coming to believe its true though. Have fun, Paul Westcott.
We should take the simplest path... Hmmm, so the simplest path includes garbage collection. Great. I've just completed one of (my 3 concurrent) projects in Java for a client that wanted use Java, wanted speech synthesis, real time etc etc, we had some rather horrible experiences with the garbage collector getting in the way, even if we tried forcing its scheduling. ANd it was differnt with VMs from differnt vendors! Ugh. Anyway we're moving onto the next. Now, switch to a CAD vendor with a 2 million line C++ program and they want to try garbage collection. Works very well until you overcommit the memory by loading a model that is too large, so some of it is out on disk. What happens when it does a GC? It touches every page in the memory. Lovely. That is the sort of performance 'improvement' you don't want. Garbage collection may be simple from a programmers perspective, but its not called garbage for nothing... Stephen
-
please, show me one place where VB meets or exceeds C++ as a "UI design language". C++ is perfect for UI design. start with a generic window class that knows something about mouse clicks and clipping; from that, create a generic button class that knows something about being pushed and sending the appropriate message when a push occurs; from that, create a button with text and a button with an image and a button with both text and an image, a button that doesn't have a 3D look and a button that does, a button that stays down when you press it and a button that is transparent. want all of your buttons to make a noise when they're pressed? change the "OnPressed" code in the base class to make a noise. all of the positioning and button behavior is in the base "button" class, but the derived classes can draw themselves however they want via virtual functions. and luckily, MS has already done most of this work in MFC. and even better, you can do all of this without having to screw around with ActiveX or COM - hooray! and, you can do it without distributing the VB runtimes - hooray! -c ---------------------- www.smalleranimals.com
*spontanteous applause* To say C++ is not for UI design is an insult to me and every other person who has designed UI's with it - no problem. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
MFC has been around for many years, ATL is getting more mature to be used. However, VB has catch-up so fast, previous advantages with VC in modern programming has became very little. Comparing VB to VC (from the eyes of marketing manager), if you are talking about memory management, code size, functionality or speed, the differences are simply too small. VB is MORE productive and powerful compare to VC in developing enterprise level application package, like it or not. Worst of all, VC often need to go through at least 2 service packs to go steady. WTL is simply a toy for hardcore C++ supporter, I seriously doubt the productivity of WTL in modern multi-tier application. I think it will suffer the same problem like AFX at the end. At the meantime, I believe MFC/ATL really need to be update to a true "Enterprise" level application tools like VB.
VB is good for UIs (sometimes) C++ is good for everything and anything and Marketing Managers rarely know what they are talking about. If you tell them that a sexy cool UI is written in TurboC they will probably fall for it, so give it a rest and spare us the trouble.:mad: