Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. The Lounge
  3. .Net, WTL and MFC/ATL

.Net, WTL and MFC/ATL

Scheduled Pinned Locked Moved The Lounge
c++toolsperformancecsharpsales
27 Posts 10 Posters 3 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Lost User

    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.

    E Offline
    E Offline
    Erik Funkenbusch
    wrote on last edited by
    #21

    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.

    1 Reply Last reply
    0
    • C Chris Losinger

      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

      P Offline
      P Offline
      Paul Westcott
      wrote on last edited by
      #22

      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.

      C L 2 Replies Last reply
      0
      • P 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.

        C Offline
        C Offline
        Chris Losinger
        wrote on last edited by
        #23

        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

        1 Reply Last reply
        0
        • L Lost User

          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...

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #24

          u r 2 1337 4 m3

          1 Reply Last reply
          0
          • P 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.

            L Offline
            L Offline
            Lost User
            wrote on last edited by
            #25

            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

            1 Reply Last reply
            0
            • C Chris Losinger

              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 Offline
              C Offline
              Christian Graus
              wrote on last edited by
              #26

              *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.

              1 Reply Last reply
              0
              • L Lost User

                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.

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #27

                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:

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups