.Net, WTL and MFC/ATL

Lost User

No way! VB sucks!!! VC++ roolz! (it's been weeks since we've had a flame war here :) )

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

Lost User

Absolutely - but I think the move to C# is the better move - even Microsoft themselves are leaning this way. I think those that hang onto the obscurities of C++ are control freaks and backseat drivers who demand to be able to control every last thing about something regardless of whether or not their input to the final solution was really worth the interference. I think there is something very Freudian about those who demand to allocate every single byte themselves in C++, who need to mess with pointers in VB, who get all hot and flushed at the thought of spending an extra week fine tuning those assembler routines. Let it go. Some of us actually have to get some work done, and if that means we develop something in 50% of the time that is, maybe, 5% slower, then what is the issue? In 6 months time the average user will have machines that run 30% fast than when you developed it.

Lost User

:mad:

Chris Losinger

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

ip

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:

Simon Capewell

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)

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

NormDroid

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 :(

Simon Capewell

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.

Lost User

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

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

Chris Maunder

I think you'll find VB7 finally gets over this. cheers, Chris Maunder

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

Christian Graus

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.

Juan Carlos Cobas

I also do agree with you. Mainly if you have to write scientific applications. Not to mention real time apps.

Juan Carlos Cobas

I also do agree with you. Mainly if you have to write scientific applications. Not to mention real time apps

Juan Carlos Cobas

I also do agree with you. Mainly if you have to write scientific applications. Not to mention real time apps

Erik Funkenbusch

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.

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.