Zafir Anjum
May 17th, 1998, 02:02 PM
If so, when do you prefer to use VB and when do you stay with VC++. Do you
use any of the other RAD tools.
use any of the other RAD tools.
Click to See Complete Forum and Search --> : Do you use Visual Basic (or VBA) ?
Martin
May 18th, 1998, 03:16 AM
Give a child a hammer and the whole world looks like a nail ;-)
I did several projects with MS-Access (and other tools).
I think development in Access is faster and easier than in C++, I use it for smaller, data-based and not time-critical applications.
One example: an application for monitoring incoming and outgoing repairs, just some data entry forms and some reports.
I did several projects with MS-Access (and other tools).
I think development in Access is faster and easier than in C++, I use it for smaller, data-based and not time-critical applications.
One example: an application for monitoring incoming and outgoing repairs, just some data entry forms and some reports.
Maria Keesling
May 21st, 1998, 04:05 PM
I have used VBA extensively to automate Office functionality. I prefer VB and VBA to C++ because VB is TRULY RAD, whereas C++ does not seem to have been designed for RAD. C++ is a lower-level language that requires much more time to absorb and apply. The user interface for the programmer is much more developed in VB. My recommendation to you is to use VB if you can, but if you need the object-orientation of C++, you're going to have to plug away.
Ferenc Kis
May 22nd, 1998, 10:52 AM
I made some projects in VB5 in very short time, even I doesn't have experience in VB. Everithing was easy until they (customers) ask me to make some improvements to the basic functionallity of the common controls (eg. multiple selection and drag&drop in Tree control). I start looking for some ActiveX controls with this features, but each one has something bad (bugs, poor interface, high price...). Then I red some articles form this site and I decide to write that controls in VC++. It vas a good choice.
Even I like much more to write programs in VC++, sometimes I'm forced to use VB by economic and other circumstances, not directly related to programming.
Even I like much more to write programs in VC++, sometimes I'm forced to use VB by economic and other circumstances, not directly related to programming.
R.D. Holland
June 3rd, 1998, 05:41 PM
I typically use VB to quickly write test drivers that exercise our apps via automation. This comes in real handy if you have a large complicated project which you don't want to modify in order to test (such as adding "temporary commands" that exercise your interfaces or code by varying argument values).
This works real well in our case since we already build automation capablilty into our apps for customers and ISVs.
This works real well in our case since we already build automation capablilty into our apps for customers and ISVs.
Heather
June 17th, 1998, 03:44 PM
I like to use Visual Basic when working with data that fits best in a relational (Access-like) database or when I need to prototype a larger app "quick and dirty".
I find that Visual Basic is very flexible in writing apps quickly and with an acceptable number of features, but if you have a longer amount of time to work on a project, C++ is by FAR the more powerful tool to use.
Of course, C++ doesn't work well when writing programs for relational databases, but hey, Microsoft Access was WRITTEN in Visual Basic, so it seems like that's the better language to handle databases anyhow.
In practice, I like working in Visual Basic better, but I do use both languages.
I find that Visual Basic is very flexible in writing apps quickly and with an acceptable number of features, but if you have a longer amount of time to work on a project, C++ is by FAR the more powerful tool to use.
Of course, C++ doesn't work well when writing programs for relational databases, but hey, Microsoft Access was WRITTEN in Visual Basic, so it seems like that's the better language to handle databases anyhow.
In practice, I like working in Visual Basic better, but I do use both languages.
Herbie Smith
June 23rd, 1998, 11:06 AM
I just started playing with VB (had it for ages, never installed it) writing small, dialog-based apps. I'm impressed! It took me only a single afternoon to write my first app (converting data in tab-delimited text files to Targa-encoded files for the POV-Ray raytracer - including MS Chart preview). Not bad considering I really had little idea what I was doing with VB and spent most of that time looking in help files. A previous version, written in C++, took a day and a half to write, with less functionality.
I don't know that I'd use it for anything large, but then I get the impression that I've barely scratched the surface of VB's capabilities. I intend to investigate further when I have the time.
I don't know that I'd use it for anything large, but then I get the impression that I've barely scratched the surface of VB's capabilities. I intend to investigate further when I have the time.
Paul Doherty
June 24th, 1998, 05:34 PM
VB is awesome! I've used many languages (Pascal, C, Assembly, Cobol) and it is by far the best environment I've worked in yet. It has a steep learning curve for the interface but once you get used to it the help it gives in building the interface elements is incredibly useful (and not to mention removes the mundane tasks and lets you get to what you're trying to do)!
I wrote my PC DiskMaster in VB4 & 5 Check it out...
--
24 hours in a day, 24 beers in a case... coincidence? I think not.
Paul Doherty CNA/CNE/MCP+I/MCSE
http://www.dfw.net/~pdoherty
Home of PC DiskMaster File/Dir Manager for Win95/98/NT4
I wrote my PC DiskMaster in VB4 & 5 Check it out...
--
24 hours in a day, 24 beers in a case... coincidence? I think not.
Paul Doherty CNA/CNE/MCP+I/MCSE
http://www.dfw.net/~pdoherty
Home of PC DiskMaster File/Dir Manager for Win95/98/NT4
Teddy Andrews
July 6th, 1998, 06:55 PM
I have some questions about Visual Basic, but this is a C++ site so I wont bother you with any of them. I am however wondering, is visual basic the better choice for manipulating other programs? There are alot of those "punters" and other things out on AOL, all done in Visual Basic. Is this because alot of the people making these are younger kids that do not want to spend the time learning languages such as C++ or is it because it is better time wise or performance wise? ohh, and this is a very nicely done site. Props!
Steve Naughton
July 14th, 1998, 01:50 PM
We've all heard it argued that VB is far better at RAD than VC++. I've always been suspicious about such statements. Perhaps VC++ is just more difficult to become proficient in, and that someone proficient in VC++ can crank out apps ALMOST as quickly as a VB person.
I want to hear from people who are proficient at BOTH, cause I've already heard it all from those knowing only one environment.
I want to hear from people who are proficient at BOTH, cause I've already heard it all from those knowing only one environment.
Jeff Kohn
July 15th, 1998, 11:56 AM
I'd consider myself an advanced VB programmer. As for VC++, I'd say I'm proficient in dialog-based apps and ActiveX development, but I haven't really worked with the Doc-View stuff. For form-based apps, VB is still going to be quicker to develop in. For instance, using a dialog in VC++ you have to go to the trouble of tying your controls to your member variables; ClassWizard can save some time here, but in VB this isn't necessary at all. VB has better database support IMHO. VB also makes ActiveX development (both client and server) much easier.
On the other hand, VB can be a very frustrating language sometimes. There are some things you just can't do because VB's designers didn't think you'd ever want to. It seems that you often have to resort to API calls to do lots of stuff anyway, and using the Win32 API from VB is more tedious and difficult than using it from VC++.
For small projects, VB can save you time over VC++, but not as much as the VB advocates would have you believe. For larger projects or applications that will ship to lots of customers, VC++ provides more flexibility, control, and robustness; the fact that development time is increased slightly probably isn't going to be the deciding factor for these types of projects.
Jeff
On the other hand, VB can be a very frustrating language sometimes. There are some things you just can't do because VB's designers didn't think you'd ever want to. It seems that you often have to resort to API calls to do lots of stuff anyway, and using the Win32 API from VB is more tedious and difficult than using it from VC++.
For small projects, VB can save you time over VC++, but not as much as the VB advocates would have you believe. For larger projects or applications that will ship to lots of customers, VC++ provides more flexibility, control, and robustness; the fact that development time is increased slightly probably isn't going to be the deciding factor for these types of projects.
Jeff
Neal Glover
July 15th, 1998, 03:08 PM
For me VB comes in handiest when working with clients who have no idea what kind of a user interface they want. You can set up a really complicated "app" consisting of dozens of forms and dialogs, fill them with fake data, and demonstrate the program flow with little effort. Then you can change the UI right there as they decide what they like and don't.
Once the UI is finalized you're ready to run in VB or VC. Of course this does have a downside too. Clients like these also tend to see the ease at which you made the changes the first time and get upset when it takes longer and costs more to make changes to the real app later on.
Once the UI is finalized you're ready to run in VB or VC. Of course this does have a downside too. Clients like these also tend to see the ease at which you made the changes the first time and get upset when it takes longer and costs more to make changes to the real app later on.
Chris Onyak
August 6th, 1998, 06:43 PM
These are all very easy to do inside Visual Basic. (With the help of APIs) I know of an API that can help you do exactly what you want but I can't think of it just now. If your interested, e-mail me or go to my site to find out the name of the API.
Jeff Kohn
August 7th, 1998, 09:59 AM
My problem with this approach is that by the time you start messing with API's, callbacks, or window subclassing in VB, you're losing the advantage in ease of use that VB is supposed to provide. It's been my experience that using API calls is easier in VC++ than in VB. After all, the whole point of VB is supposed to be drag-n-drop visual form design without having to resort to API programming.
Jeff
Jeff
Jeevan Sunkersett
August 24th, 1998, 12:45 AM
Hi,
I tend to use VB more than VC, however both have their advt + dis-advt.
In VB I can get apps working fast and almost effortlessly compared to VC.
But then some things simply cannot be done in VB,
like pointer arithmetic for eg.
In such cases I use VC to develop a DLL and acheive the result.
I find VB a better development tool for DB apps.
Apart from this :
-----------------
I am currently strengthing my skills on MFC + Doc-View.
Can u please suggest books/ web-sites on the same which I could use,
something else than "Inside VC++", by "Kruglinski",
something concentrating on the features of WinNT, ActiveX developemnt, ....
Also I would like to mention:
http://www.codeguru.com is a very good site.
TIA!!
regards
Jeevan
I tend to use VB more than VC, however both have their advt + dis-advt.
In VB I can get apps working fast and almost effortlessly compared to VC.
But then some things simply cannot be done in VB,
like pointer arithmetic for eg.
In such cases I use VC to develop a DLL and acheive the result.
I find VB a better development tool for DB apps.
Apart from this :
-----------------
I am currently strengthing my skills on MFC + Doc-View.
Can u please suggest books/ web-sites on the same which I could use,
something else than "Inside VC++", by "Kruglinski",
something concentrating on the features of WinNT, ActiveX developemnt, ....
Also I would like to mention:
http://www.codeguru.com is a very good site.
TIA!!
regards
Jeevan
Dick Warg
September 15th, 1998, 01:38 PM
Before windows and networked PCs I wrote all critical applications in C using an Informix database or a dBase clone. These all ran on Unix system. As PC/Windows/LAN became common on desktops I shifted to VB and Access and have a lot of Access/VBA applications running right now. But for the major strategic system re-write I chose VC++/MFC as the primary language for several reasons.
First, since I find I can still easily support C code that I wrote 12 years ago I trust that C++ will have the same long life. Besides I'm getting old and I prefer to focus on one language if I can.
Second, Windows is mostly written in C/C++ (and assembler) and almost all of the literature is in C/C++. This isn't as important in writing user interface code, but I need to integrate SQL server functions and interplant communications as well as COM/DCOM so I get as much as I can from books, magazines and forums like Code Guru. Developing a large project requires that I be able to marshall solution resources efficiently and a major resource is the professional literature.
Third, the ability to create new classes and sub-class easily, provide powerful tools for solving complex problems. In the long run this more than makes up for the extra work required for form and report creation and ten years from now the efficiency, stablity and supportability of the code will be more valuable than the relatively modest extra time it took to write it.
I have also used Borland's Delphi and C++ builder for getting applications going quickly. Each has it's advantages and they are both RAD. The problem that I have experienced dozens of times over the years is that eventually the limits of the RAD wrapper (be it COBOL, RPG, dBase, JAM or VBA) confound me (in the case of Borland tools it's the Borland Database Engine) and I spend more time working around the RAD tools than I saved by using them in the first place. I have gradually realized that most of the difficulties with Windows RAD tools come from their effort to mask the messaging nature of the Windows API and make each application look like it is a single user DOS application with a prettier face.
VC++ and MFC have very powerful classes for dealing with SQL databases and dynamic structures. Those are the real keys to my applications. The interface tools are not all that bad once I begin to understand their Windows Messaging nature and how to exploit it. But it is hard work learning, not always obvious and intuitive, and I wish I already knew all this material by heart. Having this forum and all of its resources makes that work much more pleasant.
First, since I find I can still easily support C code that I wrote 12 years ago I trust that C++ will have the same long life. Besides I'm getting old and I prefer to focus on one language if I can.
Second, Windows is mostly written in C/C++ (and assembler) and almost all of the literature is in C/C++. This isn't as important in writing user interface code, but I need to integrate SQL server functions and interplant communications as well as COM/DCOM so I get as much as I can from books, magazines and forums like Code Guru. Developing a large project requires that I be able to marshall solution resources efficiently and a major resource is the professional literature.
Third, the ability to create new classes and sub-class easily, provide powerful tools for solving complex problems. In the long run this more than makes up for the extra work required for form and report creation and ten years from now the efficiency, stablity and supportability of the code will be more valuable than the relatively modest extra time it took to write it.
I have also used Borland's Delphi and C++ builder for getting applications going quickly. Each has it's advantages and they are both RAD. The problem that I have experienced dozens of times over the years is that eventually the limits of the RAD wrapper (be it COBOL, RPG, dBase, JAM or VBA) confound me (in the case of Borland tools it's the Borland Database Engine) and I spend more time working around the RAD tools than I saved by using them in the first place. I have gradually realized that most of the difficulties with Windows RAD tools come from their effort to mask the messaging nature of the Windows API and make each application look like it is a single user DOS application with a prettier face.
VC++ and MFC have very powerful classes for dealing with SQL databases and dynamic structures. Those are the real keys to my applications. The interface tools are not all that bad once I begin to understand their Windows Messaging nature and how to exploit it. But it is hard work learning, not always obvious and intuitive, and I wish I already knew all this material by heart. Having this forum and all of its resources makes that work much more pleasant.
David Terracino
September 22nd, 1998, 02:19 PM
I prefer to think of VB as a RAP language, rather than RAD.
R apid
A pplication
P rototyping
It's easy to throw together an idea of what your dialogs might look like and stuff in a VB program, and perhaps you have some advantage of not having to manually connect your variables to your controls (although ClassWizard automates this), but in the long run, I don't see much savings. :)
Dave
R apid
A pplication
P rototyping
It's easy to throw together an idea of what your dialogs might look like and stuff in a VB program, and perhaps you have some advantage of not having to manually connect your variables to your controls (although ClassWizard automates this), but in the long run, I don't see much savings. :)
Dave
Scott M.
September 24th, 1998, 06:30 PM
Experience has shown that the coding of an app takes much less time than the up front design. That being said, I think VB might actually hinder application development because it is so easy to be undisiplined in VB as compared to C++ and bad programming practices are easy to pick up. In that case you might actually end up spending more time fixing bugs than developing. So, in short, RAD in any enviroment is a myth. The more time up front you spend analysing your project the more return you will see. There is a rule called the 1-10-100 rule. This programming rule states that for each 1 unit of work spent in up front design you will save 10 units during development and 100 units during deployment. After 10 years of experience I have found this to be true more times than not.
Mike Haney
September 30th, 1998, 02:59 PM
I started as a VB programmer in college, but I have been using VC almost exclusively for over 5 years now. I have only found a use for VB in a few instances - such as prototypes and quick test harnesses for ActiveX controls.
I use VC mostly because it is a RAD - ROBUST Application Development - environment. I think VB encourages sloppy programming. VB encourages poorly designed programs because it is so easy to just jump in. Also, if you do take the time to do a proper program design, it is very difficult to translate your object-oriented design to VB. Conversely, these designs map very well to C++ (or Java).
For a substantial project, a proficient VC++ programmer can deliver the application just as quickly as a proficient VB programmer over the course of the entire lifecycle. And, the VC++ program will most likely be more robust, have better performance, and will be more easily maintained.
In short, any perceived development speed advantages of VB are short-sighted and will prove costly in the long run.
I use VC mostly because it is a RAD - ROBUST Application Development - environment. I think VB encourages sloppy programming. VB encourages poorly designed programs because it is so easy to just jump in. Also, if you do take the time to do a proper program design, it is very difficult to translate your object-oriented design to VB. Conversely, these designs map very well to C++ (or Java).
For a substantial project, a proficient VC++ programmer can deliver the application just as quickly as a proficient VB programmer over the course of the entire lifecycle. And, the VC++ program will most likely be more robust, have better performance, and will be more easily maintained.
In short, any perceived development speed advantages of VB are short-sighted and will prove costly in the long run.
phil
October 11th, 1998, 02:04 PM
i have no schooling as a programmer however i have programmed in assembly, C (not Visual C), BASIC, and recently Visual Basic... it appears that MFC and Visual C++ is the way to go for real apps but for me the main advantage of C++ is the execution speed. obviously C will always be faster than BASIC but i see no reason why Microsoft cannot create a faster Visual Basic. i used powerBASIC to automate a genetics lab and it was so fast that it wasn't even worth coding the thing in C. i remember programming in assembly as a child when computers only had like 8K RAM and thinking C was lame and **** now i sometimes program in Visual BASIC... BASIC ? yak. anyway i would still like to see a faster Visual Basic because computing has changed a lot anyway, it seems that most time is spent calling up other peoples' code... when your OS took up 16k of ROM and you had only 8K RAM it was fun to re-invent the world :).
Phil
October 11th, 1998, 02:04 PM
i have no schooling as a programmer however i have programmed in assembly, C (not Visual C), BASIC, and recently Visual Basic... it appears that MFC and Visual C++ is the way to go for real apps but for me the main advantage of C++ is the execution speed. obviously C will always be faster than BASIC but i see no reason why Microsoft cannot create a faster Visual Basic. i used powerBASIC to automate a genetics lab and it was so fast that it wasn't even worth coding the thing in C. i remember programming in assembly as a child when computers only had like 8K RAM and thinking C was lame and **** now i sometimes program in Visual BASIC... BASIC ? yak. anyway i would still like to see a faster Visual Basic because computing has changed a lot anyway, it seems that most time is spent calling up other peoples' code... when your OS took up 16k of ROM and you had only 8K RAM it was fun to re-invent the world :).
phil
October 16th, 1998, 05:11 PM
Phil
October 16th, 1998, 05:11 PM
phil
October 16th, 1998, 05:54 PM
i'm taking the plunge and learning Visual C++... i'll buy the standard edition this weekend. 4 days ago when i became interested i read some simple code and NOTHING made sense but now it doesn't seem that tough. MFC seems like an incredible step instead of re-inventing the wheel or API.
5 months ago i started learning Visual BASIC and my first app is now done... i'm also using installshield. i have this habit of not reading manuals so i spent a couple days trying to figure out what a form was, what an event was, what a method was... you get the picture :). i had never programmed for Windows... only DOS until then.
i think i'll be able to make a good comparison post for VB versus VC. VC seems very powerful due to MFC and AppWizard and ClassWizard (i'm sure i'll use them to start). well, off i go... the only thing i'm dreading are those **** semicolons and brackets... i hate C's syntax... oh well...
phil :)
5 months ago i started learning Visual BASIC and my first app is now done... i'm also using installshield. i have this habit of not reading manuals so i spent a couple days trying to figure out what a form was, what an event was, what a method was... you get the picture :). i had never programmed for Windows... only DOS until then.
i think i'll be able to make a good comparison post for VB versus VC. VC seems very powerful due to MFC and AppWizard and ClassWizard (i'm sure i'll use them to start). well, off i go... the only thing i'm dreading are those **** semicolons and brackets... i hate C's syntax... oh well...
phil :)
Phil
October 16th, 1998, 05:54 PM
i'm taking the plunge and learning Visual C++... i'll buy the standard edition this weekend. 4 days ago when i became interested i read some simple code and NOTHING made sense but now it doesn't seem that tough. MFC seems like an incredible step instead of re-inventing the wheel or API.
5 months ago i started learning Visual BASIC and my first app is now done... i'm also using installshield. i have this habit of not reading manuals so i spent a couple days trying to figure out what a form was, what an event was, what a method was... you get the picture :). i had never programmed for Windows... only DOS until then.
i think i'll be able to make a good comparison post for VB versus VC. VC seems very powerful due to MFC and AppWizard and ClassWizard (i'm sure i'll use them to start). well, off i go... the only thing i'm dreading are those **** semicolons and brackets... i hate C's syntax... oh well...
phil :)
5 months ago i started learning Visual BASIC and my first app is now done... i'm also using installshield. i have this habit of not reading manuals so i spent a couple days trying to figure out what a form was, what an event was, what a method was... you get the picture :). i had never programmed for Windows... only DOS until then.
i think i'll be able to make a good comparison post for VB versus VC. VC seems very powerful due to MFC and AppWizard and ClassWizard (i'm sure i'll use them to start). well, off i go... the only thing i'm dreading are those **** semicolons and brackets... i hate C's syntax... oh well...
phil :)
Chris Bilson
October 27th, 1998, 12:58 AM
We use visual basic here simply because it IS faster to develop a (SMALL) app in VB than in VC. I can crank out the shell for a small app (10 ~ 15 modules) in a couple of days.
However, with all of the headaches we have had with controls that won't register, and inrinsic calls not doing what they are supposed to do, I prefer to use VC for larger (more complex) projects, or projects for which we have a looser deadline. Using VC gives us the power to make the app more robust (run on any 32-bit machine in any language without problems) and gives us a better debugging environment.
However, with all of the headaches we have had with controls that won't register, and inrinsic calls not doing what they are supposed to do, I prefer to use VC for larger (more complex) projects, or projects for which we have a looser deadline. Using VC gives us the power to make the app more robust (run on any 32-bit machine in any language without problems) and gives us a better debugging environment.
phil
October 29th, 1998, 03:50 PM
first some backgound... i have always loved computers... i first started programming at 12. i learned the basics of assembly language for a 6502 (atari) processor while on a plane trip to florida. back then i would used BASIC to POKE values into memory and then CALL the routines, the speed was impressive. 4 years later i was in college hacking away at things and writing a lot of assembly code... mostly because the machines were slow. i learned (chronologically) assembly [several processors], BASIC, C, pascal, and fortran. i remembered thinking that assembly was the only way to go... how wrong i was... computers became faster and C routines took only twice the time to execute but were much more readable and easier to write.
i've always programmed in DOS but recently i learned Visual BASIC and very recently Visual C++... Visual C++ is the first language ever that took me several days to write something meaningful... not too bad i guess for someone who 8 months ago didn't know the meaning of an object, property, method, or event :) [sadly i learned what they were after i'd been using them for many months]. i recently created my first real app and i realize now that the executable is only half the battle... installation (packaging) can be messy.
anyways here are my thoughts...
given:
(1) the current rate of raw processing power doubling
(2) the modular nature of the Windows OS, controls, and components, etc.
the future:
(1) a higher level language will overtake C++ just as it overtook assembly
(2) development speed will take priority over app execution speed
the specifics:
(1) microsoft will release a powerful Visual BASIC compiler
(2) under it, VB executables will run half the speed of VC++
i know what you're thinking... nutcase ! hehe :). but wait... obviously there will ALWAYS be a need for assembly and C++ programming, especially at the top (microsoft etc.)... serious job security. lets face it though... weather we use MFC or MSVBVM60 we are calling a lot of other people's code, at least for the 'visual' part. just as C++ is not C, VB is not the BASIC of the past... it is structured and object oriented.
envision the future. lets be conservative... VB is 10 times slower than VC++... even if moore's law slows to every 2 years by 6.6 years (2/log2) VB apps will run as fast as C++ apps do today...
God willing and we all live another 10 years we'll get to see some hillarious stuff... intel convincing people to buy 'Cray' computers to do word processing and write e-mail, live video chat rooms, DVD burners commonplace, T1 in every home... ok maybe i'm going a little overboard now :).
i really do see VC++ going the way of assembly [replacing it yet again] but i won't be happy about it... lets face it though the processors are getting super fast... and i'm sure that when a person first writes an MPEG-1 decoder in interpreted BASIC it'll make us all very very sick :)...
so what do you think ?
peace,
phil :)
i've always programmed in DOS but recently i learned Visual BASIC and very recently Visual C++... Visual C++ is the first language ever that took me several days to write something meaningful... not too bad i guess for someone who 8 months ago didn't know the meaning of an object, property, method, or event :) [sadly i learned what they were after i'd been using them for many months]. i recently created my first real app and i realize now that the executable is only half the battle... installation (packaging) can be messy.
anyways here are my thoughts...
given:
(1) the current rate of raw processing power doubling
(2) the modular nature of the Windows OS, controls, and components, etc.
the future:
(1) a higher level language will overtake C++ just as it overtook assembly
(2) development speed will take priority over app execution speed
the specifics:
(1) microsoft will release a powerful Visual BASIC compiler
(2) under it, VB executables will run half the speed of VC++
i know what you're thinking... nutcase ! hehe :). but wait... obviously there will ALWAYS be a need for assembly and C++ programming, especially at the top (microsoft etc.)... serious job security. lets face it though... weather we use MFC or MSVBVM60 we are calling a lot of other people's code, at least for the 'visual' part. just as C++ is not C, VB is not the BASIC of the past... it is structured and object oriented.
envision the future. lets be conservative... VB is 10 times slower than VC++... even if moore's law slows to every 2 years by 6.6 years (2/log2) VB apps will run as fast as C++ apps do today...
God willing and we all live another 10 years we'll get to see some hillarious stuff... intel convincing people to buy 'Cray' computers to do word processing and write e-mail, live video chat rooms, DVD burners commonplace, T1 in every home... ok maybe i'm going a little overboard now :).
i really do see VC++ going the way of assembly [replacing it yet again] but i won't be happy about it... lets face it though the processors are getting super fast... and i'm sure that when a person first writes an MPEG-1 decoder in interpreted BASIC it'll make us all very very sick :)...
so what do you think ?
peace,
phil :)
Phil
October 29th, 1998, 03:50 PM
first some backgound... i have always loved computers... i first started programming at 12. i learned the basics of assembly language for a 6502 (atari) processor while on a plane trip to florida. back then i would used BASIC to POKE values into memory and then CALL the routines, the speed was impressive. 4 years later i was in college hacking away at things and writing a lot of assembly code... mostly because the machines were slow. i learned (chronologically) assembly [several processors], BASIC, C, pascal, and fortran. i remembered thinking that assembly was the only way to go... how wrong i was... computers became faster and C routines took only twice the time to execute but were much more readable and easier to write.
i've always programmed in DOS but recently i learned Visual BASIC and very recently Visual C++... Visual C++ is the first language ever that took me several days to write something meaningful... not too bad i guess for someone who 8 months ago didn't know the meaning of an object, property, method, or event :) [sadly i learned what they were after i'd been using them for many months]. i recently created my first real app and i realize now that the executable is only half the battle... installation (packaging) can be messy.
anyways here are my thoughts...
given:
(1) the current rate of raw processing power doubling
(2) the modular nature of the Windows OS, controls, and components, etc.
the future:
(1) a higher level language will overtake C++ just as it overtook assembly
(2) development speed will take priority over app execution speed
the specifics:
(1) microsoft will release a powerful Visual BASIC compiler
(2) under it, VB executables will run half the speed of VC++
i know what you're thinking... nutcase ! hehe :). but wait... obviously there will ALWAYS be a need for assembly and C++ programming, especially at the top (microsoft etc.)... serious job security. lets face it though... weather we use MFC or MSVBVM60 we are calling a lot of other people's code, at least for the 'visual' part. just as C++ is not C, VB is not the BASIC of the past... it is structured and object oriented.
envision the future. lets be conservative... VB is 10 times slower than VC++... even if moore's law slows to every 2 years by 6.6 years (2/log2) VB apps will run as fast as C++ apps do today...
God willing and we all live another 10 years we'll get to see some hillarious stuff... intel convincing people to buy 'Cray' computers to do word processing and write e-mail, live video chat rooms, DVD burners commonplace, T1 in every home... ok maybe i'm going a little overboard now :).
i really do see VC++ going the way of assembly [replacing it yet again] but i won't be happy about it... lets face it though the processors are getting super fast... and i'm sure that when a person first writes an MPEG-1 decoder in interpreted BASIC it'll make us all very very sick :)...
so what do you think ?
peace,
phil :)
i've always programmed in DOS but recently i learned Visual BASIC and very recently Visual C++... Visual C++ is the first language ever that took me several days to write something meaningful... not too bad i guess for someone who 8 months ago didn't know the meaning of an object, property, method, or event :) [sadly i learned what they were after i'd been using them for many months]. i recently created my first real app and i realize now that the executable is only half the battle... installation (packaging) can be messy.
anyways here are my thoughts...
given:
(1) the current rate of raw processing power doubling
(2) the modular nature of the Windows OS, controls, and components, etc.
the future:
(1) a higher level language will overtake C++ just as it overtook assembly
(2) development speed will take priority over app execution speed
the specifics:
(1) microsoft will release a powerful Visual BASIC compiler
(2) under it, VB executables will run half the speed of VC++
i know what you're thinking... nutcase ! hehe :). but wait... obviously there will ALWAYS be a need for assembly and C++ programming, especially at the top (microsoft etc.)... serious job security. lets face it though... weather we use MFC or MSVBVM60 we are calling a lot of other people's code, at least for the 'visual' part. just as C++ is not C, VB is not the BASIC of the past... it is structured and object oriented.
envision the future. lets be conservative... VB is 10 times slower than VC++... even if moore's law slows to every 2 years by 6.6 years (2/log2) VB apps will run as fast as C++ apps do today...
God willing and we all live another 10 years we'll get to see some hillarious stuff... intel convincing people to buy 'Cray' computers to do word processing and write e-mail, live video chat rooms, DVD burners commonplace, T1 in every home... ok maybe i'm going a little overboard now :).
i really do see VC++ going the way of assembly [replacing it yet again] but i won't be happy about it... lets face it though the processors are getting super fast... and i'm sure that when a person first writes an MPEG-1 decoder in interpreted BASIC it'll make us all very very sick :)...
so what do you think ?
peace,
phil :)
Joshua Muskovitz
November 5th, 1998, 03:23 PM
I have long said: "When computers are infinitely fast, everyone will program in COBOL." The simple truth is that compiler technology has closed the gap on hand-coded assembler, thus C++ has replaced Assembly code for the most part. (Of course, there are always exceptions to this.) C++ will go by the wayside as a primary development language only after some other language can close the current gap. This will take a while. VB certainly doesn't provide sufficient control over one's environment like VC++, and Java, while getting closer to providing the same level of functionality is quite a long ways off in terms of performance.
I believe that C++ is going to be around for quite a while. I think a better question is "Will MFC go the way of the Interrupt-driven DOS API?" What newer and better APIs or frameworks will come along to replace the MFC programming model?
I believe that C++ is going to be around for quite a while. I think a better question is "Will MFC go the way of the Interrupt-driven DOS API?" What newer and better APIs or frameworks will come along to replace the MFC programming model?
phil
November 10th, 1998, 07:16 PM
thanks Joshua for the input. ok here is the deal... i've been trying to find a fast basic compiler that can do Active X, and learning Visual C++ at night. after fooling with the the compiler i realize that MFC really has taken a lot of the pain out of programming in VC++. i ended up rewriting most of the code for my app one night in C++ and figured the rest out the next day. screw BASIC... hehe.
begin. i do feel that learning VB helped immensely and it is a great programming language but the fact that it is slow and you have to reboot on installation to get it to run on another person's machine due to OLEAUT32.DLL is a hastle. i wrote to microsoft asking them to fix these problems. i didn't want to learn Delphi because i hate pascal's syntax more than C's :). end.
what i honestly would like (and i *know* it aint gonna happen) is for microsoft to redo the VC++ compiler with BASIC's syntax and integrate the files and some of the programming like the MESSAGE MAPs etc (Wizard entrance only). if microsoft could have approached Visual BASIC this way it would have been a truly killer language... based on VC++ and MFC. many of the apps i write i could do in HTML by inserting objects and using VBScript but what the end-user is in-store for death: (1) load IE, load VB runtimes, load Active X's, reboot, jump though a hoop, stop watching star-trek... meanwhile try to get that app through a 33.6 modem... forget it !
if (so there ! i'm a MFC VC++ programmer now... i'm sick of looking for a new language... someone fix BASIC before i get used to these **** semicolons and brackets) { aaaahhhh !; };
phil :)
ps that VC++ compiler loves me... maybe i can be in the guiness book of MFC records for writing an if statement and generate 10 errors... so i forgot some semicolons and a bracket and i only put in one equals sign and some of the variables are undeclared... hehe :)!
parting thought: how come you can do the same exact thing in VC++ and in VB and it take ten times longer in BASIC ? sounds like a compiler problem to me... there is nothing inherently wrong with the BASIC language, syntax should be irrelevant.
begin. i do feel that learning VB helped immensely and it is a great programming language but the fact that it is slow and you have to reboot on installation to get it to run on another person's machine due to OLEAUT32.DLL is a hastle. i wrote to microsoft asking them to fix these problems. i didn't want to learn Delphi because i hate pascal's syntax more than C's :). end.
what i honestly would like (and i *know* it aint gonna happen) is for microsoft to redo the VC++ compiler with BASIC's syntax and integrate the files and some of the programming like the MESSAGE MAPs etc (Wizard entrance only). if microsoft could have approached Visual BASIC this way it would have been a truly killer language... based on VC++ and MFC. many of the apps i write i could do in HTML by inserting objects and using VBScript but what the end-user is in-store for death: (1) load IE, load VB runtimes, load Active X's, reboot, jump though a hoop, stop watching star-trek... meanwhile try to get that app through a 33.6 modem... forget it !
if (so there ! i'm a MFC VC++ programmer now... i'm sick of looking for a new language... someone fix BASIC before i get used to these **** semicolons and brackets) { aaaahhhh !; };
phil :)
ps that VC++ compiler loves me... maybe i can be in the guiness book of MFC records for writing an if statement and generate 10 errors... so i forgot some semicolons and a bracket and i only put in one equals sign and some of the variables are undeclared... hehe :)!
parting thought: how come you can do the same exact thing in VC++ and in VB and it take ten times longer in BASIC ? sounds like a compiler problem to me... there is nothing inherently wrong with the BASIC language, syntax should be irrelevant.
Phil
November 10th, 1998, 07:16 PM
thanks Joshua for the input. ok here is the deal... i've been trying to find a fast basic compiler that can do Active X, and learning Visual C++ at night. after fooling with the the compiler i realize that MFC really has taken a lot of the pain out of programming in VC++. i ended up rewriting most of the code for my app one night in C++ and figured the rest out the next day. screw BASIC... hehe.
begin. i do feel that learning VB helped immensely and it is a great programming language but the fact that it is slow and you have to reboot on installation to get it to run on another person's machine due to OLEAUT32.DLL is a hastle. i wrote to microsoft asking them to fix these problems. i didn't want to learn Delphi because i hate pascal's syntax more than C's :). end.
what i honestly would like (and i *know* it aint gonna happen) is for microsoft to redo the VC++ compiler with BASIC's syntax and integrate the files and some of the programming like the MESSAGE MAPs etc (Wizard entrance only). if microsoft could have approached Visual BASIC this way it would have been a truly killer language... based on VC++ and MFC. many of the apps i write i could do in HTML by inserting objects and using VBScript but what the end-user is in-store for death: (1) load IE, load VB runtimes, load Active X's, reboot, jump though a hoop, stop watching star-trek... meanwhile try to get that app through a 33.6 modem... forget it !
if (so there ! i'm a MFC VC++ programmer now... i'm sick of looking for a new language... someone fix BASIC before i get used to these **** semicolons and brackets) { aaaahhhh !; };
phil :)
ps that VC++ compiler loves me... maybe i can be in the guiness book of MFC records for writing an if statement and generate 10 errors... so i forgot some semicolons and a bracket and i only put in one equals sign and some of the variables are undeclared... hehe :)!
parting thought: how come you can do the same exact thing in VC++ and in VB and it take ten times longer in BASIC ? sounds like a compiler problem to me... there is nothing inherently wrong with the BASIC language, syntax should be irrelevant.
begin. i do feel that learning VB helped immensely and it is a great programming language but the fact that it is slow and you have to reboot on installation to get it to run on another person's machine due to OLEAUT32.DLL is a hastle. i wrote to microsoft asking them to fix these problems. i didn't want to learn Delphi because i hate pascal's syntax more than C's :). end.
what i honestly would like (and i *know* it aint gonna happen) is for microsoft to redo the VC++ compiler with BASIC's syntax and integrate the files and some of the programming like the MESSAGE MAPs etc (Wizard entrance only). if microsoft could have approached Visual BASIC this way it would have been a truly killer language... based on VC++ and MFC. many of the apps i write i could do in HTML by inserting objects and using VBScript but what the end-user is in-store for death: (1) load IE, load VB runtimes, load Active X's, reboot, jump though a hoop, stop watching star-trek... meanwhile try to get that app through a 33.6 modem... forget it !
if (so there ! i'm a MFC VC++ programmer now... i'm sick of looking for a new language... someone fix BASIC before i get used to these **** semicolons and brackets) { aaaahhhh !; };
phil :)
ps that VC++ compiler loves me... maybe i can be in the guiness book of MFC records for writing an if statement and generate 10 errors... so i forgot some semicolons and a bracket and i only put in one equals sign and some of the variables are undeclared... hehe :)!
parting thought: how come you can do the same exact thing in VC++ and in VB and it take ten times longer in BASIC ? sounds like a compiler problem to me... there is nothing inherently wrong with the BASIC language, syntax should be irrelevant.
Joshua Muskovitz
November 11th, 1998, 12:06 AM
You have to remember -- VB is *not* a compiled language in the true sense of the word. That is to say, VB doesn't produce machine code. It produces something half-way there, bytecode. This is structured, and stripped of all but the essentials, but it still needs to be interpreted. That's why you have to have VBRUNxxx.DLL in order to run anything. VBRUN contains an interpreter for running the "compiled" VB code. And that's why it runs really slowly.
VC++ produces native machine code, and thus it runs a hell of a lot faster. Of course, to do anything useful, you need to link in MFCxx.DLL, but this code is also native machine code, so you don't really see much of a performance hit -- sertainly not of anywhere near the same as with VB.
You say you would like to see VB with MFC, but the real problem is that VB just isn't a real object oriented language. You would do much better to really learn VC++ and just build things yourself. As you have seen, it really doesn't take much to put together a basic app. Visual Studio is a fabulous toolset, and coding goes quite fast.
While it is true that you can whip together a VB app in about ten minutes, so what? What is the real issue is how long it takes to produce a *real* application, which does all sorts of complicated things. This is where VC++ really shines, once you know how to do it (and that just takes practice). For simple apps, use whatever tool you like.
But don't count on Microsoft building anything of substance into VB. They don't have any reason to, and they NEVER do things just to be nice. Ever.
VC++ produces native machine code, and thus it runs a hell of a lot faster. Of course, to do anything useful, you need to link in MFCxx.DLL, but this code is also native machine code, so you don't really see much of a performance hit -- sertainly not of anywhere near the same as with VB.
You say you would like to see VB with MFC, but the real problem is that VB just isn't a real object oriented language. You would do much better to really learn VC++ and just build things yourself. As you have seen, it really doesn't take much to put together a basic app. Visual Studio is a fabulous toolset, and coding goes quite fast.
While it is true that you can whip together a VB app in about ten minutes, so what? What is the real issue is how long it takes to produce a *real* application, which does all sorts of complicated things. This is where VC++ really shines, once you know how to do it (and that just takes practice). For simple apps, use whatever tool you like.
But don't count on Microsoft building anything of substance into VB. They don't have any reason to, and they NEVER do things just to be nice. Ever.
phil
November 11th, 1998, 01:12 AM
Joshua
i understand what you were saying about VB executables not being machine code. i used to program in assembly for fun back when the 386 was new. i personally like BASIC's syntax but cannot find a good compiler so i'm stuck with C++. i used to do PowerBASIC under DOS and it was as fast as C++ and almost as structured.
i've learned VB and VC++ in the last 9 months and the two languages are surprisingly similar. using the MFC appwizard and classwizard seems very similar to VB. i admit i do not fully understand some of the framework output (i bought VC++ on Oct 16). MFC makes VC++ worth coding in.
i agree with you that microsoft will not 'fix' VB but VB most surely could be implemented to follow MFC and be converted directly into machine code and into stand alone executables. i think MS doesn't want that kind of power accessed that easily. in my eyes programming shouldn't be difficult when we have 300 MHz computers on our desktop... the compilers should be better. with MFC and wizards and ActiveX components many programs are just glue... mine that is (i'm not a programmer by trade but i've done plenty). i'm sure coding a VC++ app without MFC is a real treat.
i hadn't programmed for windows before 8 months ago. i was just very shocked that my choices for creating an application were very limited. the way i see it it's VB, Delphi (pascal), Visual Studio, Java and VC++. my app did run fine under VB and if the VB 'compiler' was as good as PowerBASIC's was i wouldn't have had to port it to VC++. oh well.
thanks again for your comments
phil :)
ps do other implementations of the C++ language have their own equivalent to MFC ? or is microsoft the only one ?
pps i got the VC++ compiler for $50... came with MSDN CD's and .EXE's are redistributable... can't beat that !
i understand what you were saying about VB executables not being machine code. i used to program in assembly for fun back when the 386 was new. i personally like BASIC's syntax but cannot find a good compiler so i'm stuck with C++. i used to do PowerBASIC under DOS and it was as fast as C++ and almost as structured.
i've learned VB and VC++ in the last 9 months and the two languages are surprisingly similar. using the MFC appwizard and classwizard seems very similar to VB. i admit i do not fully understand some of the framework output (i bought VC++ on Oct 16). MFC makes VC++ worth coding in.
i agree with you that microsoft will not 'fix' VB but VB most surely could be implemented to follow MFC and be converted directly into machine code and into stand alone executables. i think MS doesn't want that kind of power accessed that easily. in my eyes programming shouldn't be difficult when we have 300 MHz computers on our desktop... the compilers should be better. with MFC and wizards and ActiveX components many programs are just glue... mine that is (i'm not a programmer by trade but i've done plenty). i'm sure coding a VC++ app without MFC is a real treat.
i hadn't programmed for windows before 8 months ago. i was just very shocked that my choices for creating an application were very limited. the way i see it it's VB, Delphi (pascal), Visual Studio, Java and VC++. my app did run fine under VB and if the VB 'compiler' was as good as PowerBASIC's was i wouldn't have had to port it to VC++. oh well.
thanks again for your comments
phil :)
ps do other implementations of the C++ language have their own equivalent to MFC ? or is microsoft the only one ?
pps i got the VC++ compiler for $50... came with MSDN CD's and .EXE's are redistributable... can't beat that !
Phil
November 11th, 1998, 01:12 AM
Joshua
i understand what you were saying about VB executables not being machine code. i used to program in assembly for fun back when the 386 was new. i personally like BASIC's syntax but cannot find a good compiler so i'm stuck with C++. i used to do PowerBASIC under DOS and it was as fast as C++ and almost as structured.
i've learned VB and VC++ in the last 9 months and the two languages are surprisingly similar. using the MFC appwizard and classwizard seems very similar to VB. i admit i do not fully understand some of the framework output (i bought VC++ on Oct 16). MFC makes VC++ worth coding in.
i agree with you that microsoft will not 'fix' VB but VB most surely could be implemented to follow MFC and be converted directly into machine code and into stand alone executables. i think MS doesn't want that kind of power accessed that easily. in my eyes programming shouldn't be difficult when we have 300 MHz computers on our desktop... the compilers should be better. with MFC and wizards and ActiveX components many programs are just glue... mine that is (i'm not a programmer by trade but i've done plenty). i'm sure coding a VC++ app without MFC is a real treat.
i hadn't programmed for windows before 8 months ago. i was just very shocked that my choices for creating an application were very limited. the way i see it it's VB, Delphi (pascal), Visual Studio, Java and VC++. my app did run fine under VB and if the VB 'compiler' was as good as PowerBASIC's was i wouldn't have had to port it to VC++. oh well.
thanks again for your comments
phil :)
ps do other implementations of the C++ language have their own equivalent to MFC ? or is microsoft the only one ?
pps i got the VC++ compiler for $50... came with MSDN CD's and .EXE's are redistributable... can't beat that !
i understand what you were saying about VB executables not being machine code. i used to program in assembly for fun back when the 386 was new. i personally like BASIC's syntax but cannot find a good compiler so i'm stuck with C++. i used to do PowerBASIC under DOS and it was as fast as C++ and almost as structured.
i've learned VB and VC++ in the last 9 months and the two languages are surprisingly similar. using the MFC appwizard and classwizard seems very similar to VB. i admit i do not fully understand some of the framework output (i bought VC++ on Oct 16). MFC makes VC++ worth coding in.
i agree with you that microsoft will not 'fix' VB but VB most surely could be implemented to follow MFC and be converted directly into machine code and into stand alone executables. i think MS doesn't want that kind of power accessed that easily. in my eyes programming shouldn't be difficult when we have 300 MHz computers on our desktop... the compilers should be better. with MFC and wizards and ActiveX components many programs are just glue... mine that is (i'm not a programmer by trade but i've done plenty). i'm sure coding a VC++ app without MFC is a real treat.
i hadn't programmed for windows before 8 months ago. i was just very shocked that my choices for creating an application were very limited. the way i see it it's VB, Delphi (pascal), Visual Studio, Java and VC++. my app did run fine under VB and if the VB 'compiler' was as good as PowerBASIC's was i wouldn't have had to port it to VC++. oh well.
thanks again for your comments
phil :)
ps do other implementations of the C++ language have their own equivalent to MFC ? or is microsoft the only one ?
pps i got the VC++ compiler for $50... came with MSDN CD's and .EXE's are redistributable... can't beat that !
Viktor Martensson
November 19th, 1998, 05:09 PM
Hi!
Random input.
Our company tries to build as many applications using VB as possible. The superior speed of development, the ease of integrating third party components and the (nowadays not unique) ability to change the code runtime.
However, sometimes we are lucky, and find projects that are not feasible to implement in VB, but rather in java or C++. This is much more fun, but also a lot (LOT) more time consuming.
We programmers do never ever favour a language because of its usefullness, it is all, and will always be a matter of religion. (A un founded oppinion).
Regarding MFC. MFC is one of the worst class libraries on the market. If you want to be really productive, try to reduce your dependency on MFC and use ATL or whatever. Especially, stay away from MFC networking!!
/Viktor Martensson
Shaken, not stirred
Inherited, not deligated.
Random input.
Our company tries to build as many applications using VB as possible. The superior speed of development, the ease of integrating third party components and the (nowadays not unique) ability to change the code runtime.
However, sometimes we are lucky, and find projects that are not feasible to implement in VB, but rather in java or C++. This is much more fun, but also a lot (LOT) more time consuming.
We programmers do never ever favour a language because of its usefullness, it is all, and will always be a matter of religion. (A un founded oppinion).
Regarding MFC. MFC is one of the worst class libraries on the market. If you want to be really productive, try to reduce your dependency on MFC and use ATL or whatever. Especially, stay away from MFC networking!!
/Viktor Martensson
Shaken, not stirred
Inherited, not deligated.
Steve Bailey
November 20th, 1998, 05:36 PM
Viktor,
Have you ever ever used CFtpConnection class in MFC? Is this buggy? Just wondering.
Also:
After getting knowledgeable with API and MFC, is ATL another long struggle?
I've written two small apps with win32 and one app with MFC.
thanks
Steve
Have you ever ever used CFtpConnection class in MFC? Is this buggy? Just wondering.
Also:
After getting knowledgeable with API and MFC, is ATL another long struggle?
I've written two small apps with win32 and one app with MFC.
thanks
Steve
Viktor Martensson
November 20th, 1998, 07:27 PM
Well, the CHttpConnection leaks resources and memory badly anyway. We had a application once that was leaking so much memory because of that class so we had to rewrite it and use a different technique. A assume that the entire CInternet collection is just as buggy.
Note that the "memory leak dump" provided when you close a MFC program doesnt tell you the whole story. Try using BoundsChecker and you will see how much memory MFC is leaking ;)
If you are writing a small app that needs to load web pages, consider java (Even though it is sooo boring to use)
About ATL. The ATL is mostly for developing COM components. So if you ar a little bit familiar with COM and knows how C++ really works, it shouldt be a hassle. (Note that ATL is not as extensive framework as MFC).
I can recomend some books if you are interested in COM. (But if so, mail me ;)
Best regards
Ville
Note that the "memory leak dump" provided when you close a MFC program doesnt tell you the whole story. Try using BoundsChecker and you will see how much memory MFC is leaking ;)
If you are writing a small app that needs to load web pages, consider java (Even though it is sooo boring to use)
About ATL. The ATL is mostly for developing COM components. So if you ar a little bit familiar with COM and knows how C++ really works, it shouldt be a hassle. (Note that ATL is not as extensive framework as MFC).
I can recomend some books if you are interested in COM. (But if so, mail me ;)
Best regards
Ville
phil
November 21st, 1998, 10:53 PM
i was afraid i'd offended by the mfc comments... in the last month i've switched from VB to VC++ to Borland C++ Builder... each has their good and bad points... as far as BASIC goes i've decided to stop coding in it... C++ only for now. VC++ is great at activeX but the framework and wizards are garbage... Builder 3 has a great framework and is better than even VB in terms of ease but activeX is garbage on it... i had no idea the choices for languages was so horrible out there. are there any other RAD C++ compilers out there ? if microsoft made a hybrid of VB and VC++ (doubtful) or Borland improved Builder (i'm sure they're hard at work on it) we'd be in luck...
we'll see...
phil :)
we'll see...
phil :)
Phil
November 21st, 1998, 10:53 PM
i was afraid i'd offended by the mfc comments... in the last month i've switched from VB to VC++ to Borland C++ Builder... each has their good and bad points... as far as BASIC goes i've decided to stop coding in it... C++ only for now. VC++ is great at activeX but the framework and wizards are garbage... Builder 3 has a great framework and is better than even VB in terms of ease but activeX is garbage on it... i had no idea the choices for languages was so horrible out there. are there any other RAD C++ compilers out there ? if microsoft made a hybrid of VB and VC++ (doubtful) or Borland improved Builder (i'm sure they're hard at work on it) we'd be in luck...
we'll see...
phil :)
we'll see...
phil :)
phil
November 22nd, 1998, 03:37 AM
the thing about using both is that you end up with VB code looking ugly because it's full of API calls... kind of defeats VB's purpose. the problem is that VC++ should be upgraded to something similar to Borland C++ Builder. under VC++ you end up spending all your time screwing around with the GUI instead of making your code... it needs to be upgraded. there is a point of diminishing returns hacking away trying to implement these things... with Borland the IDE does the dialog (forms) code... when will VC++ do this ? even if Borland's forms were twice as 'slow' (and they probably are close to same speed) who cares... with 300 MHz machines the dude's gonna end up waiting for what 100 mS ? give it up... they should implement VB features in VC++ and let programmers program and be productive... RAD is everything... so what happens when computers get to 10GHz speed... we'll all have to do VB because by the time we write the code in C++ someone else will have it out first. how come this seems so clearly needed but it's not being implemented ? well what is microsoft's incentive ? we sit around dealing with VC, meanwhile someone creates the compiler equivalent of VB or even better VB's forms with C++'s power (C++ Builder 3 is almost there... needs real activeX support)... i just hope either microsoft implements the changes or it's gonna be hell trying to keep up.
phil :)
phil :)
Phil
November 22nd, 1998, 03:37 AM
the thing about using both is that you end up with VB code looking ugly because it's full of API calls... kind of defeats VB's purpose. the problem is that VC++ should be upgraded to something similar to Borland C++ Builder. under VC++ you end up spending all your time screwing around with the GUI instead of making your code... it needs to be upgraded. there is a point of diminishing returns hacking away trying to implement these things... with Borland the IDE does the dialog (forms) code... when will VC++ do this ? even if Borland's forms were twice as 'slow' (and they probably are close to same speed) who cares... with 300 MHz machines the dude's gonna end up waiting for what 100 mS ? give it up... they should implement VB features in VC++ and let programmers program and be productive... RAD is everything... so what happens when computers get to 10GHz speed... we'll all have to do VB because by the time we write the code in C++ someone else will have it out first. how come this seems so clearly needed but it's not being implemented ? well what is microsoft's incentive ? we sit around dealing with VC, meanwhile someone creates the compiler equivalent of VB or even better VB's forms with C++'s power (C++ Builder 3 is almost there... needs real activeX support)... i just hope either microsoft implements the changes or it's gonna be hell trying to keep up.
phil :)
phil :)
Viktor Martensson
November 22nd, 1998, 07:26 AM
Ok, I must admit that MFC is not all bad :)
Also I must admit that my experience of other class librarys on the market is somewhat limited. The thing is that MFC have several times proven harder to get usefull results from then coding in plain C. I learned C++ before I could write C programs that compiled, so it is not a religous matter :)
I use MFC today because it is the "standard Windows" class library/FW. Most of our customers use it as well, and we cant motivate a change of technology. I also use it because the appwizard helps me build all those small nifty test apps in notime.
I believe that MFC could become a great class library/FW if the "reengineered" it and skipped the backward compability. Call it MFC2 or whatever, just get rid of the 16 bit junk :)
A friend of mine once told me that I sound irritated whenever I post something on message borards. I am not irritated, but my english skills limits my expressiveness :)
Have a non-hangover day! :)
Also I must admit that my experience of other class librarys on the market is somewhat limited. The thing is that MFC have several times proven harder to get usefull results from then coding in plain C. I learned C++ before I could write C programs that compiled, so it is not a religous matter :)
I use MFC today because it is the "standard Windows" class library/FW. Most of our customers use it as well, and we cant motivate a change of technology. I also use it because the appwizard helps me build all those small nifty test apps in notime.
I believe that MFC could become a great class library/FW if the "reengineered" it and skipped the backward compability. Call it MFC2 or whatever, just get rid of the 16 bit junk :)
A friend of mine once told me that I sound irritated whenever I post something on message borards. I am not irritated, but my english skills limits my expressiveness :)
Have a non-hangover day! :)
Dimarzio
November 25th, 1998, 03:30 PM
No thanks, I'd rather write my own code thank you.. Maybe one day you can buy a piece of software to go through the whole software life cycle and even package the software in shrink wrapped little boxes, then you we can kick back and play quake all day :) No but seriously, the problem with wizards and IDE's writing your code is the lack of customization. Sure this might be a great solution for building smaller more "standard" software, but most of the time wizard’s fall short on building larger projects that require more customization. Also, another way to look at it is: "The more you abstract from developing code, the closer comes the day that our jobs as programmers will disappear." well.. you would however inprove your Quake skills :P
Tomaz Stih
November 28th, 1998, 06:53 AM
Agree with you 75%. But you should consider not only business applications but also real time software, engineering software when talking about programmers... In fact, trying several RAD tools I've come to conclusion that RAD only works for user interfaces.
There are 2 issues I would like to point out about using VC++ as a RAD tool:
1. VC++ is a tool - it is best used for components, utilities, system code... It is not a good front-end database tool. You should ask yourself why do we need a tool better than Visual Basic? Add threads to VB and it has it all. Writing simple business applications in VB will still be cheaper that writing them in C++. There are less skilled programmers avaliable for C++, the code needs more testing, etc... If you need something that VB does not provide - use component.
2. It is very important to make RAD tools as simple as possible so that it will be possible for people outside software development to use them. For example economists. Why would you need skilled C++ programmer to work on ridiculusly simple code?
The quality of business applications will drop but business applications are all about the needed results and if the results are satisfactory with VB app then VB will be used if the quality pays off then C++ will be used.
Lp,
Tomaz
tomaz@nameco.com
http://www.nameco.com/tomaz.stih
There are 2 issues I would like to point out about using VC++ as a RAD tool:
1. VC++ is a tool - it is best used for components, utilities, system code... It is not a good front-end database tool. You should ask yourself why do we need a tool better than Visual Basic? Add threads to VB and it has it all. Writing simple business applications in VB will still be cheaper that writing them in C++. There are less skilled programmers avaliable for C++, the code needs more testing, etc... If you need something that VB does not provide - use component.
2. It is very important to make RAD tools as simple as possible so that it will be possible for people outside software development to use them. For example economists. Why would you need skilled C++ programmer to work on ridiculusly simple code?
The quality of business applications will drop but business applications are all about the needed results and if the results are satisfactory with VB app then VB will be used if the quality pays off then C++ will be used.
Lp,
Tomaz
tomaz@nameco.com
http://www.nameco.com/tomaz.stih
Tomaz Stih
November 30th, 1998, 04:37 AM
Hello Phil.
Agree with you about the RAD. I think big mistake of VC is forcing document/view interface. As OLE uses similar technique I can see a pattern here. But newcomers have troubles understanding doc/view without prior understanding of app/windows concept (and the API concept) which is not supported in help tutorials very well.
Actually this is an interesting leak in OO programming. It is true, you need not know how some object work. But in order to use it you need to know how the API works and in order to use doc/view you need to know how app/wnd works... :-(
As you mentioned - MS is a corporation and it is not in MS interest to produce C++ compiler that people could use to easily produce software that could compete with MS products. There is the domain of Microsoft and there is a domain of us, mere mortals. We should only write Document/View programs, components... If you want to produce a good system tool with MFC there's a lot of work to be done and there are obsticles in MFC which will prevent you from using your own style and good practise of OO programming. So you are right.
There is a lot to be done to VC++ to become a tool we need instead of tool MS needs to control the industry.
ps.
Thanks for calling me a professional programmer. :-) Anyway I am not that narrow minded technical type and I was using an economist merely as a stereotype as you Americans use lawyers.
Regards,
Tomaz
Agree with you about the RAD. I think big mistake of VC is forcing document/view interface. As OLE uses similar technique I can see a pattern here. But newcomers have troubles understanding doc/view without prior understanding of app/windows concept (and the API concept) which is not supported in help tutorials very well.
Actually this is an interesting leak in OO programming. It is true, you need not know how some object work. But in order to use it you need to know how the API works and in order to use doc/view you need to know how app/wnd works... :-(
As you mentioned - MS is a corporation and it is not in MS interest to produce C++ compiler that people could use to easily produce software that could compete with MS products. There is the domain of Microsoft and there is a domain of us, mere mortals. We should only write Document/View programs, components... If you want to produce a good system tool with MFC there's a lot of work to be done and there are obsticles in MFC which will prevent you from using your own style and good practise of OO programming. So you are right.
There is a lot to be done to VC++ to become a tool we need instead of tool MS needs to control the industry.
ps.
Thanks for calling me a professional programmer. :-) Anyway I am not that narrow minded technical type and I was using an economist merely as a stereotype as you Americans use lawyers.
Regards,
Tomaz
rick
December 22nd, 1998, 01:17 AM
Party on dude !
Rick
December 22nd, 1998, 01:17 AM
Party on dude !
rick
December 22nd, 1998, 01:31 AM
I should have elaborated more in my previous remark.
My company's response to the RAD issue was to develop our own
app framework and wizards. Our vesion of a wizard is an app
that generates other apps. You could almost call it a virus.
Our business is automation system software and we can build a
new app in a matter of minutes now. Because of our architecture,
we have a HUGE code reuse rate that saves immense amounts of
effort. I could go on but I am starting to sound like a salesman,
heaven forbid !
This was our response because we agree with the preceding remarks :
today's tools leave a lot to be desired and while our product is
not the be-all and end-all of RAD, it is very effective for our
purposes.
Best of luck in your endeavors and Party On !
Rick
My company's response to the RAD issue was to develop our own
app framework and wizards. Our vesion of a wizard is an app
that generates other apps. You could almost call it a virus.
Our business is automation system software and we can build a
new app in a matter of minutes now. Because of our architecture,
we have a HUGE code reuse rate that saves immense amounts of
effort. I could go on but I am starting to sound like a salesman,
heaven forbid !
This was our response because we agree with the preceding remarks :
today's tools leave a lot to be desired and while our product is
not the be-all and end-all of RAD, it is very effective for our
purposes.
Best of luck in your endeavors and Party On !
Rick
Rick
December 22nd, 1998, 01:31 AM
I should have elaborated more in my previous remark.
My company's response to the RAD issue was to develop our own
app framework and wizards. Our vesion of a wizard is an app
that generates other apps. You could almost call it a virus.
Our business is automation system software and we can build a
new app in a matter of minutes now. Because of our architecture,
we have a HUGE code reuse rate that saves immense amounts of
effort. I could go on but I am starting to sound like a salesman,
heaven forbid !
This was our response because we agree with the preceding remarks :
today's tools leave a lot to be desired and while our product is
not the be-all and end-all of RAD, it is very effective for our
purposes.
Best of luck in your endeavors and Party On !
Rick
My company's response to the RAD issue was to develop our own
app framework and wizards. Our vesion of a wizard is an app
that generates other apps. You could almost call it a virus.
Our business is automation system software and we can build a
new app in a matter of minutes now. Because of our architecture,
we have a HUGE code reuse rate that saves immense amounts of
effort. I could go on but I am starting to sound like a salesman,
heaven forbid !
This was our response because we agree with the preceding remarks :
today's tools leave a lot to be desired and while our product is
not the be-all and end-all of RAD, it is very effective for our
purposes.
Best of luck in your endeavors and Party On !
Rick
Gary Gfrant
December 28th, 1998, 04:13 PM
Reading through some of the older posts and decided to put my two cents in.
VB vs. VC as RAD? If you take a look at any significant project (>6 months?), I really see little difference. Most (> two thirds) of my time will be spent in pursuits other than coding. After design testing documentation of such I would be doing something wrong if I spent more than one third of the project timeline in actual coding. Yes VB can create the UI quicker; however, I find that I spend less time creating the code behind the UI in C++ (error trapping is an example). Over all I consider the development time in both languages about the same.
VB vs. VC as RAD? If you take a look at any significant project (>6 months?), I really see little difference. Most (> two thirds) of my time will be spent in pursuits other than coding. After design testing documentation of such I would be doing something wrong if I spent more than one third of the project timeline in actual coding. Yes VB can create the UI quicker; however, I find that I spend less time creating the code behind the UI in C++ (error trapping is an example). Over all I consider the development time in both languages about the same.
eric07
January 2nd, 1999, 09:08 PM
I've been programming under VC++ for a while now. I read a copy of C++ Builder and bought and tried it. Man i cant believe how easy it is. We seem to be in a struggle between which is better VC or Builder, Optima, etc. They seem to have different advantages for different uses. Ex. Builder is greate for front end applications, Unlike VB, Builder still incorporates c++ and all the benefits of a rad environment. I mean between VC++, C++ Builder etc. They are both C++ languages using classes, so it should be easy to go to one and another, just having to learn the ins and outs of the ide. With java coming to acceptance, look at the development tools. Over 90% of them are RAD, exept maybe for the jdk, and kawa( But even kawa give you a gui builder JForge ). Why should the rest of the C++ world have to be stuck in prehistoric ide like VC++. I know that allot of you hard core c/c++ programmer like to do everything. But in the real world of business the customer could care less that you wrote a particular piece of code and put in blood and sweat to get it to work, or if you used a 3rd party software to accomplish it. All customers care about is getting the application to them running. Compiler speed doesnt to be that relevant with cheap pc's with MHZ of power. And that is why allot of companies go to using RAD tools like VB, PowerBuilder, Delphi, etc. But for me going to VB is just a waste when I use Java and C++. There are too many things to do in life then to try figure out how a doc/view, or gui control placement occurs in your code. There are so much more things you can work on that is more applicatbale to the functionality of the program then spending hours trying to get the gui to work properly( as far as placint them ) when you can use RAD tools to just drag and drop them. We can argue about this for ever comparing VC++ is that great then a real RAD tool, but ifyou look at the market of popularity, then it seems that this argument becomes mute. Again I like RAD and C++ that is why I'm sticking to C++ Builder.
I know sound long winded.
I know sound long winded.
shellreef
January 26th, 1999, 11:54 PM
I almost never use VB(A). BASIC stands for *Beginner's* All-purpose Symbolic Instruction Code, and i'm not a beginner. I just like C++ better.
shellreef
January 27th, 1999, 12:07 AM
AMD K7's are going to start at 500MHz and use a 166MHz bus! For more information go to www.tomshardware.com
Dimarzio
February 11th, 1999, 01:57 PM
Quote-
2. It is very important to make RAD tools as simple as possible so that it will be possible for people outside software development to use them. For example economists. Why would you need skilled C++ programmer to work on ridiculusly simple code?
Fine, get an idiot basic programmer that will build you a bug filled pile of crap. Now you get to spend more money maintaining the project and then based on all the customer complaints, porting the project to C++. Basic allows you to do moronic things (AND BELIEVE ME VB PROGRAMMERS DO EM). Another thing, it's only simple in VB, it's so **** simple that the janitor can do it.. that should say it all. VB, not a chance, you get what you pay for.. and VB with COM.. heh well, that's a whole new complaint. :P
2. It is very important to make RAD tools as simple as possible so that it will be possible for people outside software development to use them. For example economists. Why would you need skilled C++ programmer to work on ridiculusly simple code?
Fine, get an idiot basic programmer that will build you a bug filled pile of crap. Now you get to spend more money maintaining the project and then based on all the customer complaints, porting the project to C++. Basic allows you to do moronic things (AND BELIEVE ME VB PROGRAMMERS DO EM). Another thing, it's only simple in VB, it's so **** simple that the janitor can do it.. that should say it all. VB, not a chance, you get what you pay for.. and VB with COM.. heh well, that's a whole new complaint. :P
Tomaz Stih
February 12th, 1999, 05:23 AM
My point was that some problems are just to irrelevant and too simple to be solved by professionals. You just don't build a software that will save you 10$ per day using 75k$ per year software engineer. This is why you have Excel, VBA, ASP, HTML and partly VB.
Examples of such software:
1. Simple intranets
2. Simple form applications
3. Simple business applications with static tables (software to handle
working/non-working days)
...
This software is sometimes not of vital importance for a company but technology pour technology.
Software engineers are expensive workers and trough optics of economy you only use them for complex problems that are worth the money. For trivial problems you either use non-professional or optionally (much better choice!) hire a Russian, Indian, Chinese or East European company. They'll do it for a can of beans.
Examples of such software:
1. Simple intranets
2. Simple form applications
3. Simple business applications with static tables (software to handle
working/non-working days)
...
This software is sometimes not of vital importance for a company but technology pour technology.
Software engineers are expensive workers and trough optics of economy you only use them for complex problems that are worth the money. For trivial problems you either use non-professional or optionally (much better choice!) hire a Russian, Indian, Chinese or East European company. They'll do it for a can of beans.
Andreas Saurwein
February 17th, 1999, 11:00 AM
The main difference is that, in one package you struggle with the basics to get your app running while with the other you struggle to do some things where you need access to the basics.
Both are great tools. Unfortunatly you have to stick to a supplied library of UI elements for this to work. Switching from one to the other means usually a lot of work.
And the worst is that you cant make the main app in the RAD tool and add the nifty stuff in another environment.
Sorry, as long as they are using their own standards we are bound to one or the other.
Both are great tools. Unfortunatly you have to stick to a supplied library of UI elements for this to work. Switching from one to the other means usually a lot of work.
And the worst is that you cant make the main app in the RAD tool and add the nifty stuff in another environment.
Sorry, as long as they are using their own standards we are bound to one or the other.
John Dias
February 19th, 1999, 01:48 AM
Does anyone have code for a procedure that would convert comma delimited files into fixed length? The code should be for Visual Basic.
Joseph M. Pumilio
March 1st, 1999, 01:32 PM
Not only do I use Visual C++, but Visual Basic also.
Visual Studio ties it all together for me.
Visual Studio ties it all together for me.
stefek Philippe
March 17th, 1999, 02:41 AM
J'ai un problème quand je veux insérer un état dans un état principal. Dans mon sous-état(subReport) j'utilise des propriétés "Line" pour dessiner un graph à l'aide de module externe.
Quand j'ouvre le sous-état séparemment, je peux voir le graph, mais si je veux le voir apparaître dans un autre état, un message d'erreur me dit que l'état est mal orthographié, ou qu'il n'est pas ouvert.
Alors, comment faire apparaître le contenu d'un sous-état dans un état principal, s'il ne s'agit que de dessin ?
Merci de bien vouloir répondre !
Philippe
Quand j'ouvre le sous-état séparemment, je peux voir le graph, mais si je veux le voir apparaître dans un autre état, un message d'erreur me dit que l'état est mal orthographié, ou qu'il n'est pas ouvert.
Alors, comment faire apparaître le contenu d'un sous-état dans un état principal, s'il ne s'agit que de dessin ?
Merci de bien vouloir répondre !
Philippe
Jeff Coffman
March 18th, 1999, 07:38 PM
MFC does suck in the frame work regard! Has anyone used Borland's VCL or OWL, and can you make a comparision??
Thanks,
Jeff Coffman
Thanks,
Jeff Coffman
Once and Future Consultant
March 19th, 1999, 11:09 AM
The problem with MFC is that it started life something like a decade ago. Ten years
in the development of C++ is a long time. The last decade has been a busy time
indeed in this area.
For example: I just read a book by a "big name" in object oriented design. The book
was copyrighted 1991. It claimed that C++ did not provide exception handling. Now,
that may well have been true in 1991, I don't know. But it does show the rapidity of
change in C++.
MFC could certainly do with a major re-design. Backward compatibility is getting to be
much less of a benefit these days. Things that were only slightly awkward when the
package started life are turning into oozing sores now.
My favourite thing to whine about is how you can't easily pick one class out and use
it without dragging the entire framework along. Try to use CSocket in a non-MFC
app, for example. Possible, yes. Attractive, no. Not how a general re-usable class
behaves IMHO.
But then, that is what market competition is for. If MFC does not meet the needs of
developers as well as other products, then people will stop buying it and buy those
others. And if MS wants to stay large, it will pay attention to that.
in the development of C++ is a long time. The last decade has been a busy time
indeed in this area.
For example: I just read a book by a "big name" in object oriented design. The book
was copyrighted 1991. It claimed that C++ did not provide exception handling. Now,
that may well have been true in 1991, I don't know. But it does show the rapidity of
change in C++.
MFC could certainly do with a major re-design. Backward compatibility is getting to be
much less of a benefit these days. Things that were only slightly awkward when the
package started life are turning into oozing sores now.
My favourite thing to whine about is how you can't easily pick one class out and use
it without dragging the entire framework along. Try to use CSocket in a non-MFC
app, for example. Possible, yes. Attractive, no. Not how a general re-usable class
behaves IMHO.
But then, that is what market competition is for. If MFC does not meet the needs of
developers as well as other products, then people will stop buying it and buy those
others. And if MS wants to stay large, it will pay attention to that.
codeguru.com
Copyright WebMediaBrands Inc., All Rights Reserved.
Copyright WebMediaBrands Inc., All Rights Reserved.