I have heard pretty much everyone who knows about programming say that c++ is better than VB, from what i can see, vb does the same stuff C++ does, but with more readability, also, c++ doesnt seem to have any easy way to create buttons and professional looking user interfaces the way VB does. Is there any great speed difference between the two? and what are some other pros/cons of each?
If I remember correctly once read a review on both of them with a comparisson by a microsoft employee. Overall he did say Visual Basic was better as it has a lot more functions along with the easability.
Those do pure maths a whole lot. As overall, VB is more developer friendly, while C or C++ gives you more control easily. In the other hand, you need to do much more when you have more control, so developing a program with VB is much faster than it is with C. While when the program gets big, in C it is handled better: I often hear people saying it is easy to control a big project in C, while it becomes a nightmare with VB. In the other hand, that is the point of VB: to do fast and to do small or middle sized programs.
I started out as a C/C++ programmer, well that's not the whole truth since I as many others first came in contact with computers learning the BASIC language. I was about 10-11 years old back in the late '70s and wrote cool programs like:
Code:
10 PRINT "Hello ";
20 GOTO 10
I later learned Pascal and then C and C++. But as a professional programmer I got my first job as a C++ programmer, the year was 1987 and I had just turned 19 (hmmm... I'm giving away my age here, one of those well preserved secrets). Anyhow, Windows where nowhere in sight yet so I wrote custom applications for DOS. When VB was first introduced in the early '90s I jumped on it faster then Pamela Anderson jumped Tommy Lee. But opposed to them my relationship with VB has been a long lucky one.
But of course I've had to listen to my fellow programmers who called it a "toy language". Well, in the beginning it pretty much was. But we've all heard "real" programmers say things like that forever. "You can't do this in VB", "VB is an interpreted language, you can't even make real binaries with it", "How silly it is that you need all those run-time files"... and so on forever and ever... The guys that complained the most was those that jumped on the Java train very early... and of course Java isn't interpretated or needs a huge run-time does it? (I have nothing against Java, I use it often). Also other fellow C++ programmers wrote Windows application using MFC which of course also requires huge run-times.
So much of their ados just didn't cut it. We have bin able to compile our VB programs to pure native code, creating the same kind of binaries as VC++ does, since version 5.
I admit that when it comes to speed, you can write C++ programs that runs much faster then a VB program. But in many cases that just doesn't matter. For a regular desktop application, like a word processor, speed is not the main concern since your program will have more then enough time to process any input made by the user (what kind of computer runs slower then even the fastest of typewriters can type?). Today many applications use the Net, in which case the speed issue is in the network connections and server response times rather then in the execution of code.
Let's compare another speed issue: The speed of development, to get what the customer wants delivered on time (nobody is going to pay you for two month extra work just so they will earn a few milliseconds in execution time). Well VB will be the winner here. There aren't many C++ RAD (rapid application development) tools but some do exist, like Borland C++ builder that comes with a Form package much like VB.
So which is better the apple or the pear? Well, it first come down to taste but mainly what it comes down to is the usage. What will it be used for? I still does development in C++ when I need to. But that is actually not very often.
In VB takes one quarter of the time it takes in C++ to make an application. I made an application in VB at work (for work),(the system that we use now) that is quite big ~35000 lines (server + client), (and by the way Merri, I can manage it with no problem). I made it in my free time at work between the things I was supposed to do, and it took me about a 6 months to do (I still do maintenace for it). If I were to do the same thing in C++, I am SURE I would be still working on it right now (it's been a year and 3 months since I started it).
I still use C++, but mostly when I need speed in VB...
The same way I used to use ASM in C++, now I use C++ for VB. I usually make a DLL (Or ActiveX DLL) in C++ for the things I need to do really fast, like sound processing or bitmap compression/filters, stuff that requires lot's of loops,[edit]also multithreading[/edit], etc., and use VB as the interface.
[edit]
Actually, this is a thread with a good example of when I use C++ in VB: VB - Tone Recognition
In the first post, it is VB only, and second post I made a DLL in C++ to speed up the processing (making it real-time)...
Last edited by CVMichael; Jun 16th, 2005 at 10:45 PM.
Put it this way. The speed of execution difference between VB and C++ is enormous. C++ leaves VB in the dust. A simple mathematical loop will execute in a fraction of the time that it does in VB. To put it simply, advanced programing can only be done in C++. Something as simple as keyboard hooks cannot be done in VB, leaving you to make a DLL in C++ to accomplish the task. But don't get me wrong, getting a form to pop up in C++ is a rediculous task nontheless. If you're doing it from scratch, making a window appear in C++ will take you 15 minutes to program properly. You'll never have to deal with that in VB. Adding a form using code in VB is one line :P.
To put it simply, advanced programing can only be done in C++. Something as simple as keyboard hooks cannot be done in VB
What do you consider to be advanced programming? I have no problem calling SetWindowsHookEx with WH_KEYBOARD_LL from VB to create a low level keyboard hook, or are you still using VB4?
well, i wrote two programs, with vb 6 and c++ (microsoft visual studio 6)
time it takes for c++ to count to 1000000000: 8.125 seconds
time it takes for VB to count to 1000000000 : 19.203 seconds
kinda dissapointing.. but oh well.
here is the code, i tried to get everything exactly the same:
VB
VB Code:
Option Explicit
Private Declare Function GetTickCount Lib "kernel32" () As Long
Dim firstnumber As Double
Dim secondnumber As Double
Dim thirdnumber As Double
Private Sub Form_Load()
secondnumber = 0
firstnumber = GetTickCount()
While secondnumber <= 1000000000#
secondnumber = secondnumber + 1
Wend
thirdnumber = GetTickCount()
MsgBox "time taken to count to 1000000000: " & thirdnumber - firstnumber
End Sub
C++
Code:
#include "stdafx.h"
#include "iostream.h"
#include "windows.h"
// how long does it take the computer to increment a var 100000 times?
void main()
{
double firstnumber;
double secondnumber=0;
double thirdnumber;
firstnumber = GetTickCount();
while (secondnumber <= 1000000000)
{
secondnumber++;
}
thirdnumber = GetTickCount();
cout << "time taken: " << thirdnumber - firstnumber;
}
this was using my xp home anthlon 2800 (2. GHZ)(they cheated me of 800 Mhz! i am going to have to overclock) with 512 megs ram (though that doesnt really matter)
ok, they are uploaded now.
(you have to run the C++ prog from the command prompt or batch file)
what i found disgusting was that i got an error for not capitalizing "GetTickCount" when making the C++ version of the program. I looked around and i couldnt find any option to turn case sensitivity off, (or make it like VB where it corrects all instances for you) does anyone know how to fiddle with this feature?
Well, if you in your game just going to count up to a billion it would be faster to write it in C++ . To make a little bit more fair comparison you should however remove the floating point error check in VB, since C++ doesn't have one.
Oh yes, you should also check VB doesn't need to do useless automatical data type conversion. It might do it now. I'd use Long datatype (was it, uh... Word or Integer in C?)
As you can see, to do fast code with VB6, you need experience and knowledge on how to do it... you can't just do it and claim "it is so slow!"
Joacim Andersson: i didnt get any errors when i compiled them
dee-u: i dunno, it put the symbol there after i typed the number, i tried deleting it several times
Merri: i dont see where the advanced optimizations are
Also, you didn't get any errors because it doesn't go over... nothing causes an error. VB checks for it automatically, unless you turn it off in advanced optimizations.
Joacim Andersson: i didnt get any errors when i compiled them
I didn't say that you had an error I just said that you should remove the error check. VB has built in overflow checks so you can't assign a number higher then allowed to a variable. C++ doesn't have this which could cause unexpected results. Having the check makes the code safer but slower. You can remove these error checks before you compile the program. Also a console based application will always run faster then a Windows based app. You should to be fare make the C++ app into a Win32 windowed app before you compare them.
actually, its called long in both C++ and VB, i think word is an old term for it
Type Size Values
unsigned short int 2 bytes 0 to 65,535
short int 2 bytes -32,768 to 32,767
unsigned long int 4 bytes 0 to 4,294,967,295
long int 4 bytes -2,147,483,648 to 2,147,483,647
int (16 bit) 2 bytes -32,768 to 32,767
int (32 bit) 4 bytes -2,147,483,648 to 2,147,483,647
unsigned int (16 bit) 2 bytes 0 to 65,535
unsigned int (32 bit) 2 bytes 0 to 4,294,967,295
char 1 byte 256 character values
float 4 bytes 1.2e-38 to 3.4e38
double 8 bytes 2.2e-308 to 1.8e308
yes i could have used shorter vars. but i wanted to make this take a measurable amount of time, i figured 'why not?'
The sharp simbol means that the number is a double, VB puts that automatically when the number is very large and WITHOUT decimal places (so you don't confuze it with long)
However, even when you turn optimization on you can always create faster applications using C++, nobody has claimed differently. It's just that there are very few real world applications where these differences actually make any difference.
The C++ standard doesn't set the boundaries for an int or a long. An int is at least 16-bit in size. Word is not a new term, a word is a 16bit integer. A double word (or DWORD) would be 32 bit. MS started to use these terms in VC++ simply to remove the confusion if an int is 16 or 32 bit long.
I admit that when it comes to speed, you can write C++ programs that runs much faster then a VB program. But in many cases that just doesn't matter. For a regular desktop application, like a word processor, speed is not the main concern since your program will have more then enough time to process any input made by the user (what kind of computer runs slower then even the fastest of typewriters can type?).
One thing worth mentioning is the gain C can achieve in some tasks involving processing a huge amount of data, like image processing, parsing text... Do you remember our recent cross-posts here when I badly needed help to write my own C dll's? That was definitely an example where you can incroporate some C to your VB project to really boost its the performance.
Lottery is a tax on people who are bad at maths
If only mosquitoes sucked fat instead of blood...
To do is to be (Descartes). To be is to do (Sartre). To be do be do (Sinatra)
The C++ standard doesn't set the boundaries for an int or a long. An int is at least 16-bit in size. Word is not a new term, a word is a 16bit integer. A double word (or DWORD) would be 32 bit. MS started to use these terms in VC++ simply to remove the confusion if an int is 16 or 32 bit long.
Well strictly speaking a "Word" is supposed to be as many bits as the processer, so on a 32-bit system a word is 32 bits long. A DWord therefore would be 64 bits. But in Windows a word is 16 bits and DWord 32 bits, for the same reason I suppose that an Integer in VB is 16 bits when it should really be 32 bits.
Originally Posted by outcast24817
time it takes for c++ to count to 1000000000: 8.125 seconds
time it takes for VB to count to 1000000000 : 19.203 seconds
That's extremely slow. It took me about 1.8 seconds on average. Also, your test involves floating point numbers which is always going to slow down an app, C++ as well as VB. Here's the code I used (all the advanced optimisations were on):
Code:
Option Explicit
Option Base 0
Option Compare Binary
Private Declare Function GetTickCount Lib "kernel32" () As Long
'
Public Sub Main()
Dim lngStartTime As Long
Dim lngFinishTime As Long
Dim lngMax As Long
Dim lngCounter As Long
lngMax = 1000000000
lngStartTime = GetTickCount()
While (lngCounter < lngMax)
lngCounter = lngCounter + 1
Wend
lngFinishTime = GetTickCount()
MsgBox "Time: " & lngFinishTime - lngStartTime
End Sub
Originally Posted by outcast24817
this was using my xp home anthlon 2800 (2. GHZ)(they cheated me of 800 Mhz! i am going to have to overclock)
The point of that system is not that 2800 = 2.8GHz but rather an Athlon 2800 is approximately the same speed as a 2.8 GHz Intel. I'm using a 2600 myself.
I tried making the same app in C++, it took approximately 2.5 seconds in debug mode (In the VB IDE I stopped it after a minute or so) but being a C++ n00b I couldn't get a message box to display the time taken, all it would say was "Time: " instead. I guess that's a point for the discussion, VB is a hell of a lot easier to learn than C++.
Option Base 0 means that arrays lower bound is zero which is the default so that line doesn't really do anything. You could also set Option Base 1.
Option Compare Binary is also a default setting meaning that functions like InStr and StrComp are case sensitive, "a" differs from "A". You can also set it to Option Compare Text.
It's strcat(s1, s2); s2 is added to s1. Just make sure s1 is large enough to contain s2 as well, C doesn't do it for you. This is a C function, but of course also exists in C++. However in C++ there is often a string class where the + sign have been overloaded so you can concat strings using the + sign. If the two strings are of this string class that is.
Last edited by Joacim Andersson; Jun 18th, 2005 at 08:58 AM.
what i found disgusting was that i got an error for not capitalizing "GetTickCount" when making the C++ version of the program. I looked around and i couldnt find any option to turn case sensitivity off, (or make it like VB where it corrects all instances for you) does anyone know how to fiddle with this feature?
C and C++ are case sensitive languages. long is not the same as LONG, etc.
I gave up trying to get it to work with strcat so here's what I got in the end
Code:
#include <iostream>
#include <tchar.h>
#include "windows.h"
int _tmain(int argc, _TCHAR* argv[])
{
// Count to 1000000000
long lngStartTime = 0;
long lngTime = 0;
long lngMax = 0;
long lngCounter = 0;
lngMax = 1000000000;
lngStartTime = GetTickCount();
while (lngCounter < lngMax)
{
lngCounter++;
}
lngTime = (GetTickCount() - lngStartTime);
char msg[5];
_ltoa(lngTime, msg, 10);
MessageBox(0, (LPCTSTR) msg, "Speed Test", MB_OK);
return 0;
}
In Debug configuration it clocked about 3.2 seconds and with full optimisations on it said 0 seconds everytime, even when I multiplied the maximum number by 10. This led me to think that the compiler had stripped out my loop as part of the optimisation process... So I played around with the optimisations... once it clocked 4.5s... and now I can't get any time at all no matter what I do
So I still think C++ is faster, its compiler is definitely smarter, because there aren't many situations when you want a program to count one-by-one
So I still think C++ is faster, its compiler is definitely smarter, because there aren't many situations when you want a program to count one-by-one
Is there anyone who has ever claimed that C++ would be slower? How smart the compiler is has nothing to do with the language itself. There are many C++ compilers out there, some are better then others.
"I still think C++ is definitely faster even though I couldn't actually get it to clock a time that was faster than I could achieve in Visual Basic."
"The MS VC++ compiler is definitely smarter than the MS VB6 compiler because it stripped out an unnecessary piece of code which the VB compiler left in even with full optimisations enabled."
BASIC compilers usually don't cut of loops since it's a old habit in the BASIC language to add loops to do a pause. Stripping it off would render old code useless.
These conversations can be so pointless - faster compiler? More efficient object code?
How about a good programmer vs a poor programmers - I bet that makes the biggest difference.
I come from 25+ years of mainframe programming. We've been converting all our mainframe apps to VB with MS SQL for the past four years.
We decided that all the business logic should be in T-SQL stored procedures - that's a "slow" language when compared to the likes of C++ or VB - I would imagine the crowd would say.
Recently we took our scheduling algorithm - dozens of pages of mainframe code - that puts students into high school classes. Some kids schedule in a couple of dozen iterations - some take 3000 or 4000 or more iterations. The mainframe code was all about loading memory pools with data - so that the iterations would be liquid fast.
For the past 4 years I had been suspicious that it would be required to be written in VB on the client - or C++ on the client - or C++ as an extended stored procedure on the SERVER.
Well we actually wrote it in T-SQL in a STORED PROCEDURE on the SERVER. About 6 pages of queries - some serious logic. But it takes less then 5 minutes to schedule a large high school (1500+ kids). That time beats the mainframe. Written in a 4-th generatation language like T-SQL. I was blown away.
Now we have an incredibly easy to support routine - basically a pile of queries in a package - that complete an incredibly complex task.
Moral of the story - use the best tool for you to quickly create, easily support, easily enhance - basically produce more efficiently.
Could this routine run faster in C++? Probably. Would it be worth it - from our business perspective - no.
*** Read the sticky in the DB forum about how to get your question answered quickly!! ***
Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".