Thread: VB vs. C

To add to Ober561's point:

On the VB Explorer forums, there are about 100,000 members.

I've been programming in VB for about 10 years. Though I like what I've learned so far in C, I find that VB still has it's merrits...

Take for instance, VBA (a rather crude version of VB). I build databases for a living. Out of all the guys I work with, I am the only one that writes code behind my database, all the others use Wizards to create a generic database with queries and such.

As far as commercial software, Forte is an example. The company I work for is a health insurance company. They use a Forte application to allow our Customer Service reps. the ability to browse and modify our member information... this application was written entirely in VB (with the exception of a handful of components that were written in Java).

The only drawback I see with VB is that you are required to distribute 6 basic .dll files with your application (unless the target machine already has them) whereas with C, you only need to distribute a .dll if you use something that is not native to Windows.

Believe it or not, some of the stuff you get from Microsoft is VB dependent... next time you install a Microsoft product, watch the installation and see if it installs MSVBM60.dll - that is one of the main VB redistributables.

Even better, delete this file from your Windows directory... and see which applications you have no longer run...

>Do you sell it for money? or you're selling the services WITH this program...

We have programs that are written in VB. They are used daily and generate income. So I guess it is a commercial language.

>And stop talking about RAD please
>the RAD is the worst thing that could a programmer rely on..

Agreed. But sadly, programmers are paid for results, not for good practices. And in real life, time is money and RAD is less time to pay for. So RAD is a very big deal in the business world and should be taken into account when judging the commercial value of something.

You still have to show how easy and fast you would implement my example in MFC...

>(the one with the tabs?)

Yes, the one with the tabs and multi-colored different font textboxes.

Hey, guys, why discuss a thing such long time ?

we shouldnt debate which one is better. One is tool and One is language, how could we compare them ? Just choosing the one you like and enjoying it.

we shouldnt debate which one is better. One is tool and One is language, how could we compare them ? Just choosing the one you like and enjoying it.

describing VB as a tool is a real **** !! i dont have to write anymore

>>This reminds me of those people that claim that Cobol is the most powerful language. These languages are not light weight, they do not allow you to have control over memory or even OOP features, they were made for a limited purpose, which can be duplicated by C or C++ if but not the other way around.


Hey pal. We who support VB (or COBOL for that matter) do not claim that it is the most powerful language in the world. But you must realize that C++ isn't too.

Look at it this way:

-> C++ gives you greater control, but it sacrifices time and it takes too much work.

-> VB gives you limited control, but it's sufficient enough to get you to develop any complicated high-end useful application software.


>>describing VB as a tool is a real ****


Are you actually saying that VB is some kind of feces? You're too ideological. Get down to the real world pal. If you're developing an application that does not necessarily need the vast power of C++, then you have to take advantage of a technology that will allow you to build software more easily and quickly (thereby increasing your profit's bottom line if you're in business), and that technology is VB.

Sure it is a good language for quickly creating windows applications, the reason is because it is owned by Microsoft, who owns the OS and knows the hidden API.

What hidden API do you mean?....if you mean the Kernel mode functions, then yes they are mostly undocumented, but that's hardly a problem as the full User mode API is well documented......and that api is more than enough for 99% of windows programs.....

And if you need lower level access there are other methods.....the WDM (for drivers) is pretty well documented (to my knowledge).......

Just because the OS doesn't give you 100% access to its internals, it doesn't mean the average programmer is hindered...in fact it's often a blessing as you know that other programs that your app shares the system with don't operate at a more privileged level than you....if so, they might cause problems which can stop your app from functioning properly

>>Just because the OS doesn't give you 100% access to its internals, it doesn't mean the average programmer is hindered...in fact it's often a blessing as you know that other programs that your app shares the system with don't operate at a more privileged level than you....if so, they might cause problems which can stop your app from functioning properly


Yah I agree. In other words, you don't need to know everything about your system just to be anle to make superb applications. Leave that "need-to-know-everything" to the experts. After all, not all programmers are as talented as some of our colleagues here, so VB's compatibility with the Windows OS is something worth recognizing. Am I right?

Originally posted by moemen ahmed


describing VB as a tool is a real **** !! i dont have to write anymore

sorry man, I dont meant to insult VB, in formally words, it is a software made by Microsoft just as VC, right ?

I just wanna say, VC and VB are both softs, and BASIC and C are languages, we could discuss the diference between 2 languages or 2 softs, but it is not fit compareing those which belong to different class.

As I said, it happens that each person's hobby is not the same. So, choose the one you like, that's OK.

Originally posted by TK
First of all, when you learn Win32, you learn an interface, not the implementation. It is impossible to know if they are giving you the full Win32 interface, and I have heard from Windows Internal writers that infact the full interface is not provided. So long as you are 100% Microsoft dependent there is not escape from being screwed, but at least you are not being royally screwed like the VB programmers.

But I dont think you are being screwed at all......the whole point is that 99% of the time you dont need to know these undocumented functions........the published API is more than enough and it provides almost all the fuctionality that you will ever need.....

Anyway...its not as if M$ has a list of secret functions......these functions are easy to find...its just that the documentation for their use is not provided......

Open up Dependancy Walker (I'm not dure if I got this with MSVC or maybe from the NET....but its easy to find) and load NTDLL.dll...in here you'll find loads of undocumented functions......they are there...they are no secret.......its just that access to these fuctions is given from published APIs.....CreateFile maps to NtCreateFile....so on...so on.....

There's some stuff that you as the programmer will never use directly (Like the functions for direct access to Kernel Objects)...that's becuse if you did, and did it incorrectly you would stop other programs from operating properly.......and most likely cause a nasty crash....

I dont feel screwed