I don't mean to be a dunce here...but I've been programming in QB for years...never gave another language any time...I got C++ yesterday. I wrote a simple program that prints "yo baby" every time the computer counts to a million...100 times...
In QB (compiled) it takes 20 secs to run...in C++ it takes less than 0.5 secs...a huge difference...if it turns out tha all QB code is this slow...I'm pretty sure I won't be looking back...
Here's the code I used to test. The BASIC code was compiled using 4.5...the C++ code was compiled using DEV-C++ V 5-beta.
Code:
DEFINT A-Z
FOR x = 1 TO 100
FOR t& = 1 TO 1000000
NEXT t&
PRINT " Yo--baby"; x;
NEXT x
Code:
#include <iostream>
int main()
{
for (int x=0; x<100;x++)
{
for (long int c=0; c<1000000; c++){}
std::cout << "Yo-baby " << x << " ";
}
return 0;
}
Did I make a stupid mistake, or is the C code ~ 40 times faster???!!!!!
Believe it. C++ is extremly fast; BASICs are inherently slow. The only disadvantage to C is that it can be hard to understand sometimes...
Quote:Believe it. C++ is extremly fast; BASICs are inherently slow. The only disadvantage to C is that it can be hard to understand sometimes...
All I have to say is....WOW!!!!
EDIT...I'm just dumbfounded....wow...so...if I rewrite my (fast in basic) prime finder in C++, can I expect a 40x speed increase, or was something strange going on with my counter prog???
Y'know... if you're going to use STL (<iostream> <vector> etc) you should have a
Code:
using namespace std;
after all the includes to you don't have to write std:: on everything.
Quote:Y'know... if you're going to use STL (<iostream> <vector> etc) you should have a
Code:
using namespace std;
Can you please elaborate??? I really am a C++ noob...However...no kid gloves needed...I'm experienced with computers and datatypes, etc....
EDIT...what's STL, what's <vector>...
You have to remember that QB calls functions to manipulate longs, while C++ can work with them directly using 32 bit instructions.
Also, modern C++ compilers are a lot more intelligent than QB's. Maybe it's skipping the delay loop altogether or replacing it with:
Code:
long int c = 1000000;
...which is the net effect of the loop anyway. If so, then the speed boost may not be so dramatic with other programs.
EDIT: tested his program in MS VC++ 7 and the compiler gave no warnings about c like I thought it would. My compiler optimization theory is probably wrong.
Vectors are awesome arrays, basically. They have dynamic size, so all you have to do to add a value is
Code:
vectorVar.push_back(value);
STL is the standard template library. You can use... templates
along with the new <iostream> <vector> <string> and so forth. If you don't even know about <iostream.h> or <string.h> then... poo on you.
Mango: You don't say Einstein?
Well, your comparision isn't quite fair. You're comparing a fairly decent optimizing compiler that creates pmode flat apps to qb. A real mode compiler from the 80s which has no optimizing ability. Try comparing it to QuickC from the same time, you'll see that there's barely any difference. But sure, it's not exactly a discovery. QB is slow as hell, but people here don't use ti for speed do they? They use it either becuase of their extreme lazyness is in the way of learning something new. Or simply for fun. Now i could tell you that no compiler will ever come near a good asm coder until the days computers have the ability to think. So should you switch to asm and never look back? Hardly, many qb coders knew a quite a few languages and still use it every now and again to goof around. You don't have to stop using qb just becuase you learn something new. But it's your choice really.
Yeah... um... dirty optimization is half of C's speed illusion.
If only QB could just optimize its own basic function calls....
Ya, C/C++ doesn't check array boundaries, so you can make int killer[4] and then access killer[93] since it's all pointers and memory