How does QB handle constants?

[Zack]

Just wondering...are they simply variables that QB makes sure you don't touch, or are they just symbolic, and all occurences are replaced at compile time (like C's #define)?

[Plasma]

They are symbolic.

[Zack]

Good. Memory-resident constants are slower.

[oracle]

I think more importantly, in such a memory-starved language as QB, memory-resident constants would take up memory

[Zack]

That too. :wink:
That's especially true with RPGs and such - Operation Pong uses a hundred constants, just to keep track of player frames and directions, and tiles.

[oracle]

Well, they're useful anyway. I wonder - if constants are just swapped, would it be an advantage to have a routine that runs just before a program is compiled that got swapped all the constants with their values and removed the CONST lines? So, like the way that QBMCX gets metas out and passes switches to the compiler, this program would strip consts out and put the prog in a temp file and get the compiler to compile that. Would that save a few bytes of memory?

[Zack]

Not worth the trouble, IMHO - the only memory that would be saved is at compile-time. You don't usually have to care about that - only runtime should be a worry. If constants were just protected variables, then you'd have reason to tear your hair out. :wink:

[oracle]

Oh well, if anyone needs some more mem at compile time they'll know how to do it...

[Z!re]

How come:
CONST nana=90
a=a+nana

is faster then:
a=a+90


Because it is, place it in a loop and see for yourself.

Anyone?

[1000101]

It's interesting to note, string constants are memory-resident and loaded into the variables and what-not at load-time, not compile-time. It's only numeric constants that are changed at compile-time.