Interpreter: Data type question

[audinue]

Just wonder, if we make an type-safe interpreter, and it support numeric types respectively...

Should we write operations like addition, substraction, etc... FOR EACH numeric types?

char add(char a, char b) ...
char add(short a, char b) ...
char add(int a, char b) ...

A little bit HARD WORK I think.

Anyone experienced on this?
Any better solution?

[Mario F.]

Yup. That would be terribly annoying. Make it a 3 parameter function and the number of "combinations" would increase exponentially. And 4... and 5... Ugh!

Well, we don't have to do that. C++ has Templates that, among other things, can handle these type of situations.

For starters: C++ Templates Tutorial

[audinue]

Thanks for the reply.

That makes me sure about what I do.

Thank you Mario.

However it would be terrible thing if we do that in C..

Hopefully macros will be useful here.

[CornedBee]

Meh, do what C does, introduce promotion rules. Basically in C, every integer type smaller than int is promoted to int before the actual operation, so
char = char + char
is really
char = (char)((int)char + (int)char)

Furthermore, the smaller data type is promoted to the larger one, so int + long = long, and so on. An unsigned type is "larger" than its signed counterpart.

That quite drastically cuts down the number of different operations, and if you assume a 2's complement machine and defined signed overflow (both are invalid assumption in standard C, but work in practice on most architectures), doesn't actually change the result.

[audinue]

Doesn't it affect the performance, especially in loop?

For instance:

char = (char)((long long)char + (long long)char)

Btw I taught somewhere that we should use smallest size of variable as possible in loop to gain performance.


How about double? I've seen a lot of interpreter source which using double as numeric representation.

[CornedBee]

Btw I taught somewhere that we should use smallest size of variable as possible in loop to gain performance.

That's very wrong. The fastest integer type for a CPU is usually word-sized, i.e. 32-bit on 32-bit machines. AMD64 CPUs are special in that 32-bit integers are just as fast as 64-bit integers, maybe even faster under some circumstances. But shorter integer types, while they may be as fast as longer ones, are never faster, and sometimes slower.

The problem with double is the floating point rounding errors. If you're doing all your calculations in the floating domain, users who expect integers could see very unexpected rounding errors. So yes, it's possible (I believe various JavaScript interpreters do it), but you have to be careful.

[audinue]

Thank you CornedBeef!


You opened my mind up!