Click to See Complete Forum and Search --> : VC++ vs. VB
S. Terry Woods
February 19th, 1999, 10:25 PM
I noticed that this question was touched upon but was answered prior to the
release of VB 6 that compiles to native code which seemed to be the primary
complaint. I am responsible for rewriting a core banking application that
is now in COBOL/Unix into a Window/NT enviroment. I have looked at VB and
found it to be pretty easy, but I have also looked at VC++ using MFC and
found it to be considerably more difficult. I don't want to spend the time
learning VC++ unless there is a considerable advantage to it. I would like
to know from your users what the advantages of VC++ are over VB. Please go
beyond the "macho" stuff, some told me "only wimps use VB". It seems that
VB has grown as a serious language. Are VB and VC++ on a collision course?
Steve B.
February 20th, 1999, 12:56 PM
I don't know your deadline, but if you have the luxury
of time, use VC++ for more stability and speed.
However, if you predict the slightest bit of time crunch later, and
on top of that, you don't even *know* MFC, I would say VB all the way.
You won't finish on time, otherwise. You will have the stress of:
- time
- idiosyncransies, long ways of doing certain simple things of VC/MFC
- C++ just plain takes longer than VB
This stress may cause you to further delay learning of VC++ and to
make just too many mistakes coding the app itself.
But you're not me, and you may be able to pull it off.
I'm just speaking for myself :)
Even though I've written an app in MFC already personally,
I might still consider VB the appropriate tool to fit the requirement,
time constraints, etc. for the specific job.
Best of Luck
Steve
Jim McCreary
February 22nd, 1999, 10:42 AM
My judgement may be in error since I have never used VB on a real project though as an independent contractor I own a copy and have used it to test C++ COM objects. I use VC++ for *real* work because my impression is that VB is great as long as you are using it in the way that Microsoft intended you to use it. As soon as you step outside of the box things get very sticky. With VC++ you can get down and dirty and if necessary get right to the Windows SDK level. Of course to do this you need to know the underlying details which can be a very steep learning curve.
Keep in mind that VC++ isn't that hard to use if you can just use the Class Wizard and your project is fairly simple and fits in the MS box.
For really large projects, and intermediate projects too, Object Oriented Programming is a necessity for stable, maintainable code. I have heard that with VB intial coding is fast, but debugging can take forever.
Just my two bits worth, Jim
Once and Future Consultant
February 22nd, 1999, 12:51 PM
If you do a good job at OOD, then a well constructed object oriented project is going to
be easier to debug, maintain, and modify. Probably easier to document as well.
If you do a crummy job of designing, you can make an impossible tangle in any language.
Especially if you are not strong in the methods and environment.
If you are already strong in VB and have next to no skill at VC, don't bother with VC for
a current project. But do try to learn it. Having both on your resume looks pretty good.
VB and VC have different emphasis and different strengths and weaknesses. It would
not be a bad idea to learn both.
It is also possible to use both in a single project by
creating DLLs and having the project call them. This of course implies a certain amount
of overhead in learning to create DLLs, and learning to interface the two languages.
They represent many things differently. They do many things differently.
Zhaohui Xing
February 23rd, 1999, 01:51 PM
I think VC++ and VB focus on different applications.
Before you select a tool(either VC or VB), I think
you should make every clear what type your application
is, and then you can make a correct decision. I think
in database type application, VC++ is not powerful like
VB to set up the appkication. But VC++ is every powerful
tool to set up most of professional application.
Jim McCreary
February 24th, 1999, 08:55 AM
VC++ has a very powerful, and fairly easy to use, CRecord class that works great with ODBC for database applications. You can also use DOA for database applications. If you know the tools, then VC++ has the power.
Tomaz Stih
February 26th, 1999, 05:06 AM
The only advantage of VB over VC++ is the learning courve. For
MFC it is apprx. 1/2 year. The different concepts used in the
library and being so close to API with C++ are much
more complex then simple Visual Basic object model.
But although VC++ is not a RAD once you master MFC (and you have
choosen your set of controls to handle the usual stuff such as
masked edit, grid,...) you can do things just as quickly as in
VB.
I think the two are not on a colision course. The limit between
VB and VC is in my opinion a limit between less complex and more
complex software.
I quit VB for VC++ after my first large project (management IS for
a medioum company, 200 empl.) because of it's limitations. Some
of them that I found particulary annoying:
1. If there is no ActiveX you can't do it.
2. There might be a third party ActiveX but it is too buggy
to do it anyway.
3. In my database I had long data processing intervals (calculations).
From the user point of view I handled these with progress dialog with
a series of ctrl.refresh, dlg.refresh calls and a message pump but
it's just not so gallant as with true multithreading in Vc++.
4. Forget any serious system level programming. Yes, there is interface
to DLLs but it is useless for anything complex.
VB proved a good tool for medium and small databases (with DBMS or with local database such as Access MDB). I also loved its connectivity to Excel.
Marlboro
March 4th, 1999, 06:42 AM
I agree with all the post-posted messages.
The characteristics of VC++ and VB is something like the characteristics of
Porche vs Benz. With VC++, it's very tricky to program because of the complexity.
Compared to VC++, it's more simple to code in VB. Above maintaining the program,
I would like to add the performance. I've made an internet based telephony app
using VC++. When I've first started the app, it was the first time I used VC++,
the learning curve was like the horizone. It just didn't start to climb. But,
that was the only option. I needed VC++ because the app was time-critical during
execution.
Gary Grant
March 5th, 1999, 10:05 AM
VC++ vs. VB, this question usually starts a jihad. I have used both (VB versions
3, 4 and 6). I have used Symantic C++ w/MFC and VC++ 6.0 w/MFC. I prefer using
C++. I can do a lot more with C++ than I can with VB. If you need the capability
of creating NON-ActiveX dll's you will need to use something other than VB. VB's
dll's ARE ActiveX. If you need to get real close to the operating system, it is
easier when you use C++. I have found it is easier to change default behavior of
the common controls and with C++. Yes, all of this can be done with VB (except
the non-ActiveX dll part); however, it is easier with C++, IF YOU ALREADY KNOW
VC++, MFC/ATL. The learning curve is very high for C++, MFC and ATL. Of course
if your needs include going after the Windows API you will have some heavy-duty
study even in VB. The debugging tools are better in C++.
Even with my statments above, you will find quite a bit of VB code on my
desktop. Why? It is the quickest way to create support code. I need a table
load routine for a database. I can spend fifteen minutes creating it in VB
or I can spend a half an hour in VC++. (This is a simple example and the times
are fake but you get the idea). As which language to learn, learn both just
don't try to learn both at the same time.
If this project you are working on has to be complete within the next twelve
months you probably will not be able to learn VC++ and complete it without help.
If the project is extremely complex and needs to be complete within the next
twelve months you will probably need help even with VB.
Just to start the Language Wars at your site. Have you considered using a
Windows flavor of COBOL for this project. They are out there you know.
Good luck with your project.
Ken
March 19th, 1999, 12:17 PM
Ok, I started out with VB at version 3. I started using C++ to do some of the things that I couldn't do with vb. Many different products that provide an API to their system only give you C or C++ interfaces. Or the VB interfaces dont work well. What I do now is I develope most of my front ends in VB and have all the core hard working stuff is done in C++. This give me all the functionality and SPEED of C++ but the ease of VB. In your situation, if you have to learn C++, you better stick with VB and at a later date evolve some of the backend work int C++ dll's or something similar. But so you know, I have ran some comparisons on VB vs C++ on speed and VB is right at the same performance level of C++ in many areas (file IO etc) it has a few limitations which in my situation are not acceptable at this time.
My two cents,
Ken
chris
March 22nd, 1999, 12:05 PM
I'm trying to update text in an edit box as I go thru 6 sections of code that
Takes 20 seconds to 5 minutes per section.
I've been able to get the message updated from within BUTTON1
But couldn't figure out how to do it from else where.
I'm confused.
A few details. The m_EDIT1 variable was defined
In class wizard and associated with the edit box on my dialog box.
The program I'm creating is dialog based (one dialog box)
And is called "bit128". I'm using VC++ V4.0 on Windows 95.
All help is appreciated,
-- Chris (I'm making very slow progress - thanks for the pointer to codeguru.com for MFC help)
Error - CBit128Dlg::m_EDIT1 does not specify a an object
Tried -
CBit128Dlg::UpdateData(FALSE);
Error - CWnd::UpdateData illegal call of nonstatic member function
This code works from within the BUTTON1 function which is invoked when button1 is pressed
And it works! (only 3 lines)
m_EDIT1 = _T("Start of Button1"); // set some text
UpdateData(FALSE); // send it to the edit box
refresh();// refresh the edit box by processing messages with "PeekMessage" (see below)
-- My rookie/newbie refresh function is below for reference
void refresh()
// refresh the edit box
{MSG msg = {NULL};
// Process existing messages in the application's message queue.
// When the queue is empty, do clean up and return.
while (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
// while (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE) && !m_bCancel)
{if (!AfxGetThread()->PumpMessage())
{junk++;//return; this does nothing
};//if
};//while
};//refresh
Bill
March 29th, 1999, 01:32 AM
Actually, I think VC++ is more powerful because it is merely an
encapsulation of the already-existing Win32 API. In other words, I can
work with the MFC classes directly and alter the code underneath. However,
with VB you're stuck with the encapsulation provided; period. The VB
statements are too weak to go digging underneath.
In VB, you _CAN_ access Win32 by directly opening a system DLL. But you
can't do much in the way of the program's structure, because it's already
been created for you by VB. Thats really irritating.
Furthermore, the VB disk and stream functions are a joke when compared to
VC++'s. Buffering is a real chore in VB, because there's no natural way of
doing so with such weak statements. You could, however, use one of the CRT
library functions from VC++; but why? You could've been using it in VC++ in
the first place.
I think VB is great for making quick applications like graphs, and it
really comes in handy when you're trying to work out a formula. But
otherwise, I just don't think it stacks up in functionality. Surely,
it is not a weak language, but it simply lacks structure. Even being
compiled to native code, the statements provided just aren't powerful
enough to make GOOD code.
Thats my 2 cents.
svendl
April 20th, 1999, 04:12 AM
I'd like to make a comment on the COBOL part mentioned. Several years ago we started coding a relatively large system using MF COBOL. The Windows made its way. We had to create a GUI app out of the DOS app we already had. MicroFocus ships something the call Dialog System. This handles the UI stuff. To make a very long story short: I've never experienced so much trouble in all my life. Even the simplest of things, like the SendMessage API couldn't be used. Not to mention OLE support, wich didn't work at all.
I know this was a bit off topic, but I just couldn't help myself.
Cesario Simões
April 20th, 1999, 02:01 PM
I apologize for my poor English...
I was started programming for Windows using MS C 7.0. When MSVC 1.5 appears, I migrate.
Now I`m using MSVC 5.0 because in Brazil Microsoft have some problems with customs, then, I didn`t receive MSVC 6.0...
But now I have a question: another team in my company starts using Delphi and my manager question me about "productivity". I have to decide how tool my team may use to develop our applications...
May someone give me our impressions about Delphi? I know about VB and Delphi: it`s in the same level: both are "RAD".
After read the posts in this discussion I`m inclined to use both: VC++ and VB...
Cesario Simões, Jr.
Chris Wheeler
April 20th, 1999, 03:43 PM
I have had some experiences with Delphi 3.0. Typically, Borland products (and Delphi is no exception) use odd forms of user interface objects. For instance, their Ok and Cancel boxes have a green check and a red X in them. They just don't look as "Windows standard" to me. With VB, you get the "normal" looking interface pieces including all of the common controls. For RAD, I would prefer VB over Delphi any day in any situation. I found it much easier to manage and use. I am just learning C++ and so cannot really contribute much to the VB vs. VC thread here except to say, WOW. C++ is great. Harder to learn than VB, but much much much more powerful. Keep in mind that this is my opinion and others' opinions may differ.
[b]Chris R. Wheeler, MCP[b]
Pensacola Christian College
Desktop Programmer
cwheeler@pcci.edu
Neal Stublen
May 6th, 1999, 11:35 AM
I just began using Delphi 4.0 for a new project. I would choose it over VB. It seems to be much more powerful in allowing you to derive new object from existing objects using inheritance. Creating forms provides a lot more options, such as anchoring controls to sides of the form so they automatically resize with the form. Splitter windows are a breeze to implement - just drop a splitter on your form and anchor it to another control. It is *very* easy to handle Windows messages. There are more reasons why I would choose Delphi over VB (and perhaps VC++) but these are the reasons that immediately come to mind. Delphi compiles your code a *lot* faster too!
Of course, you need to know (or learn in my case) Pascal, but if you already know VB or C++ that shouldn't take but a couple of days. I have some hesitation about the stability of Borland/Inprise, but Delphi is definitely a top-notch development tool worth considering for any project.
Crazy D
May 23rd, 1999, 09:22 AM
I'm using VB for 2 years now, I have used Borland C++ Builder for 6 months and I'm trying to learn VC++ at the moment.
To be honest, nothing can beat Borland for me. It has the ease of VB, talking about interface and stuff, and the strength of C++ (and that sille red X on the cancel button you can get rid off....).
Although, I have to say that there weren't much things that I couldn't do in VB at almost the same speed as I could get in C++.
I think, talking about RAD, that VB wins it from VC, and the power of VB6 is really good, although some things are easier to do in C with MFC, I think if you have to start, VB would be a better choice. I don't know Delphi/pascal, i heard that it codes as easy as VB, so that would be a good thing to check out.
Philippe Lhoste
May 26th, 1999, 05:30 AM
A touchy subject, handled here with quite some moderation.
Not much to add to the previous answers.
I have developped with both languages (actually VB3/4/5, Excel and Word VBA, C (SDK) and a bit of C++ with MFC), and will continue to use both (all).
As stated, VB is easy to learn, allows quick programming (very useful for prototypes and demos) but it is perhaps a bit slower and limited in some ways if you don't call APIs and don't use hooks. Note that the need to use the APIs is decreasing as the version number of VB is increasing.
There may be some surprises too: I once wrote a code which worked fine under the VB4 16-bit IDE, using its object features, but it crashed in its "compiled" form. I had to rewrite some of the code (and then duplicate some routines) to work around this problem and make it work.
One point that may or may not be important in the case of a corporate program: VB programs are not very large by themselves, but installation files are quite numerous and large! Even if you don't use any external OCX.
MFC runtimes DLL are comparatively smaller and a lot fewer!
And if you program in pure C or C++, you don't even need them (but may create a bigger executable).
It may be a bit irrationnal, but when I see a freeware written in VB, I am a bit wary to download it. If it is not available without the VB runtime (I already have them), it will be megas to download. Plus I tend to suspect the author to be less professionnal than a C programmer (now, THAT's irrationnal, I know).
Actually, I won't use a shell extension written in VB, or anything needing a lot of treatments, but I will use a VB program with a lot of UI stuff, like a calculator or CD/book database, etc.
A plus side: there is a lot of help on VB in the Internet. Dedicated sites, free code and modules, etc. There is a lot of help for MFC too, of course (here, for instance...).
--
Philippe Lhoste (Paris -- France)
loves
May 26th, 1999, 08:05 AM
I've had a read through this thread and its not
until the end that non-MS products get a mention!
If the main issue is that you want RAD times to
product, but are wary of the limitations of say
VB, then Borland C++ Builder may be the logical
answer. I guess this one won't get too much
support on this forum, but Builder gives you the
'visual' design interface of VB with the ability
to get down and dirty with the OS in C/C++.
As mentioned in the Delphi thread further on (if
you've got that far) Borland use different visual
object conventions to MFC, but having used both
I find that I no longer have a particular
preference. Both have limitations in one way or
another. If your project is a reasonably complex
one, it is probably worth the time to learn some
C++, but going down that route doesn't restrict
you to non-RAD/visual environments.
I guess that all adds up to nearly 50p worth!
Johnny Chen
May 28th, 1999, 12:31 AM
I agree your pointment. More I want to say is VB
have version ploblem. The version of Comctl32.ocx
has been changed after you install IE 4.0, and the
program complied in environment with IE 4.0 installed cannot run in the machine without installing IE 4.0(using Setup disk which is build
with VB). Only if you copy the new Comctl32.ocx to the computer can your program run.
And after your installing a high version of VB,
your old EXE program build in VB cannot run immediately.
shatterstar
May 28th, 1999, 10:37 AM
You can have this same problem with Visual C++ when those wonderful MFC DLL's have a version change as well. Version
problems with not just language specific, but more of a general problem overall.
Johnny Chen
May 31st, 1999, 04:52 AM
Dear Sir, I programed with VB5 before, after my
installing IE4, and having opened my project,
then i copy the project to the other machine which
has installed VB5 but not installed IE4, the project can't be opened with a error. I found that "Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.2#0; COMCTL32.OCX" changed in the
project file,(1.1 to 1.2) you must copy the new
version of Comctl32.ocx or change the 1.2 to 1.1.
it is the problem with VB
codeguru.com
Copyright WebMediaBrands Inc., All Rights Reserved.