03-01-2012, 10:02 AM
I agree with you about freeBasic. Still, the behaviour is the same in Turbo Basic, Visual Basic, gnu C, Visual C, Turbo C and every typed language I've tried. The expression "type" seems to be "expanded" before evaluating. The C snippet I posted in my previous post works the same in Borland Turbo C for MSDOS (int = 16 bits), gcc for Windows (DevCpp, int = 32 bits), gcc for linux (gnu gcc, int = 32 bits) and z88dk (int = 16 bits). Anyhow, it works exactly the same if you use "short" instead of int, which tends to be 16 bits always.
As far as I know, C coercion works this way: prior to evaluating an expresions, all operands are automaticly type-casted to the width of the "int" type for integer values, or to the "double" type for floating point values. Then, the expresion is evaluated and, finally, the result is automaticly casted to the lvalue type. This is true for C-like languages (which includes C++, Java or C#) and for the Microsoft BASIC standard (and the plethora of derived products).
To further ilustrate such behaviour, I've typed this code and compiled it under linux with gcc:
Note how a1 = unsigned, 32 bits integer, a2 = unsigned, 16 bits integer, a3 = signed, 16 bits integer. When I compile it and run it, I get:
As expected: during calculations, operands are automaticly casted to the int size (32 bits here), then casted to the lvalue type, and are signed accordingly.
Anyways, this is always your choice, as you are the one who's developing the compiler, but, in my opinion, if the BASIC language was, as you said, designed for simplicity's sake, having to explicitly cast your variables to meet the desired results seems somewhat contradicting. In fact, if C, which is much "lower level" have this feature, BASIC should have it more than anything.
Every typed language/platform I've used along the years behaves this way. And not just C, but BASIC flavours, Pascal, and Java. I even remember that from University, when we were writing our compiler project, that we were explicitly told to take especial care of such cases in the compiler we were writing (which was to compile a random language the teacher designed).
In particular, the case I found when calling a command or a function. I find it very intuitive that, if Draw (for example) allows negative parameters, Draw x-cx,y-cy should work even though every variable involved is unsigned. Specially on a high level language, which I expect to take care of things for me (exactly the way it manages Strings automaticly).
But again, that's a matter of your choice. I just wanted to make my point
As far as I know, C coercion works this way: prior to evaluating an expresions, all operands are automaticly type-casted to the width of the "int" type for integer values, or to the "double" type for floating point values. Then, the expresion is evaluated and, finally, the result is automaticly casted to the lvalue type. This is true for C-like languages (which includes C++, Java or C#) and for the Microsoft BASIC standard (and the plethora of derived products).
To further ilustrate such behaviour, I've typed this code and compiled it under linux with gcc:
Code:
#include <stdio.h>
int main (void) {
unsigned int a1;
unsigned short a2;
short a3;
int a4;
unsigned char b, c;
b = 255; c = 255;
a1 = b + (c << 8);
a2 = b + (c << 8);
a3 = b + (c << 8);
a4 = b + (c << 8);
printf ("%d, %d, %d, %d\n", a1, a2, a3, a4);
}Note how a1 = unsigned, 32 bits integer, a2 = unsigned, 16 bits integer, a3 = signed, 16 bits integer. When I compile it and run it, I get:
Code:
65535, 65535, -1, 65535As expected: during calculations, operands are automaticly casted to the int size (32 bits here), then casted to the lvalue type, and are signed accordingly.
Anyways, this is always your choice, as you are the one who's developing the compiler, but, in my opinion, if the BASIC language was, as you said, designed for simplicity's sake, having to explicitly cast your variables to meet the desired results seems somewhat contradicting. In fact, if C, which is much "lower level" have this feature, BASIC should have it more than anything.
Every typed language/platform I've used along the years behaves this way. And not just C, but BASIC flavours, Pascal, and Java. I even remember that from University, when we were writing our compiler project, that we were explicitly told to take especial care of such cases in the compiler we were writing (which was to compile a random language the teacher designed).
In particular, the case I found when calling a command or a function. I find it very intuitive that, if Draw (for example) allows negative parameters, Draw x-cx,y-cy should work even though every variable involved is unsigned. Specially on a high level language, which I expect to take care of things for me (exactly the way it manages Strings automaticly).
But again, that's a matter of your choice. I just wanted to make my point