Currently there are two types: Integer % (32 bits) and Float # (64/32 bits).
I'll like to see more numeric data types like other BASIC languages. This way we can optimize the amount of memory used for large arrays in portable machines.
I think short integer (16 bits) can be useful, indicated by "!" or other character.
Byte (8 bits) can be useful too, but less used.
Example:
GLOBAL largemap![]
DIM largemap![500][500] // this uses half space of an integer array
largemap[1][1] = -500
largemap[2][2] = 123
largemap[3][3] = 32767
you can use V8 beta, and "try" to use:
LOCAL number AS short // char, float, double
:nw:
Quote from: Kitty Hello on 2010-Aug-17
you can use V8 beta, and "try" to use:
LOCAL number AS short // char, float, double
Is this possible? Oh my God!!
You can define short variables, but not short arrays. Because the function DIM for shorts "DIM(short int&, int)" not exists. Then, if you write "LOCAL numbers[] AS short" you get a syntax error.
Hmm. With the following code :
LOCAL test AS short
LOCAL test2 AS char
LOCAL test3 AS float
LOCAL test4 AS double
test=1234
test2=256
DEBUG test+" "+test2+"\n"
I get the following errors :
"TestDDGui.gbas"(8) warning : probably unassigned variable : test+" "+test2+"\n"
"TestDDGui.gbas"(8) warning : implicitly created GLOBAL : test+" "+test2+"\n"
Wordcount:3 commands
compiling:
In file included from C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_tempg.cpp:2:
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_temp.h:10: error: expected initializer before '+' token
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_temp.h:10: error: expected initializer before '+' token
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_tempg.cpp:7: error: expected initializer before '+' token
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_tempg.cpp:7: error: expected initializer before '+' token
In file included from C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_temp0.cpp:1:
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_temp.h:10: error: expected initializer before '+' token
C:\Users\Nicholas\AppData\Local\Temp\glbasic\gpc_temp.h:10: error: expected initializer before '+' token
*** FATAL ERROR - Please post this output in the forum
Do you still get the error if you add spacing around the '+' signs?
DEBUG test + " " + test2 + "\n"
Could be a bug in the overloaded '+' operator.
Plus, the line: test2=256, is that allowed? ie. a direct integer to assign an ascii value? And/or is it out of range? (255 max?)
(Never tried, so I don't know).
Or do you need to assigned it with test2 = CHR$(255).
[Edit]
Is a char type a numerical type, like a byte, or a string type?
If its a string type, do we need to use a '$'?
@MrTAToad: You can define the types, but not operate because the functions aren't implemented.
Quote from: SlydogPlus, the line: test2=256, is that allowed? ie. a direct integer to assign an ascii value? And/or is it out of range? (255 max?)
In C you can assign 256 to a char, but only gets the lowest 8 bits.
256 = 100h (hexa), then the value of test2 will be 0.
Quote from: SlydogIs a char type a numerical type, like a byte, or a string type?
If its a string type, do we need to use a '$'?
The type char in C is a number, chars are 8 bits numbers.
In GCC compilers chars are signed by default (-127..128), others are unsigned.
char in not a string type, is an element of a string.
I think "char" type is difficult to implement in GLBasic.
char is signed byte (-128 .. 127)
I'll have to overload a few more operators, I guess ;)
Yes, looks like it :)
Is there an unsigned char? o;
Quote from: S. P. Gardebiter on 2010-Sep-22
Is there an unsigned char? o;
LOCAL number AS BYTE
number = 255
I have been writing same code to add new types to GLBasic using inline code, and here are the results. Maybe some functions aren't implemented for this types, but it's a beginning.
I defined two new integer types:
DGShort: uses 16 bits, range -32768..32767
DGByte: uses 8 bits, range 0..255
Add this to the end of the file glb.h file. This is part of GLBasic installation, and is located in "compiler\platform\include\glb.h" in the GLBasic folder. I don't like to change this file, but is the only way I know to define new base types. Using inline in the program doesn't work. If anybody knows other method, please say to me.
// add this lines before the last #endif
// hardyx: new integer types
typedef short DGShort;
typedef DGArray<DGShort> DGShortArray;
typedef unsigned char DGByte;
typedef DGArray<DGByte> DGByteArray;
Now you can use arrays with bytes like this, and save many memory space:
LOCAL tilemap[] AS DGByte
DIM tilemap[500][500]
Here is a GLB program to test the new types:
// --------------------------------- //
// Project: Testshort v2
//
ALLOWESCAPE TRUE
SETSCREEN 320, 240, 0
LIMITFPS 30
GOSUB TestShort
GOSUB TestByte
SHOWSCREEN
KEYWAIT
END
SUB TestShort:
// this way works ok
LOCAL map[] AS DGShort
DIM map[100]
map[0] = -32000
map[1] = 1234
map[2] = 32767
PRINT "Test short array", 0,0
PRINT "map(0) = " + map[0], 0,10
PRINT "map(1) = " + map[1], 0,20
PRINT "map(2) = " + map[2], 0,30
ENDSUB
SUB TestByte:
// this way works ok
LOCAL mapb[] AS DGByte
DIM mapb[100]
mapb[0] = 0
mapb[1] = 123
mapb[2] = 255
PRINT "Test byte array", 0,50
PRINT "mapb(0) = " + mapb[0], 0,60
PRINT "mapb(1) = " + mapb[1], 0,70
PRINT "mapb(2) = " + mapb[2], 0,80
ENDSUB
I hope you like it! :)
why aren't you using short and char instead of the typedef? Also, I fixed something with that in the next update. I have a working calculator app that uses double precision floats on iPhone. Works fine.
Did you expand operators for use with the new types ?
Quote from: Kitty Hello on 2010-Oct-28
why aren't you using short and char instead of the typedef?
Because I notice that if you use C types the array isn't created in DIM instruction using DGArray<T>, it is created instead as short& and isn't compatible with the (already defined) DGArray functions. I think you manage this types in a different way. Change the example code using short and char and you'll see.
Quote from: MrTAToad on 2010-Oct-28
Did you expand operators for use with the new types ?
Not yet, sorry. The operators are in the glb.h file.
that's what I fixed. Also the operators work now.
Thanks Gernot!!
I'm waiting for the next update.
:booze:
Quote from: hardyx on 2010-Oct-27
I have been writing same code to add new types to GLBasic using inline code, and here are the results. Maybe some functions aren't implemented for this types, but it's a beginning.
I defined two new integer types:
DGShort: uses 16 bits, range -32768..32767
DGByte: uses 8 bits, range 0..255
Add this to the end of the file glb.h file. This is part of GLBasic installation, and is located in "compiler\platform\include\glb.h" in the GLBasic folder. I don't like to change this file, but is the only way I know to define new base types. Using inline in the program doesn't work. If anybody knows other method, please say to me.
// add this lines before the last #endif
// hardyx: new integer types
typedef short DGShort;
typedef DGArray<DGShort> DGShortArray;
typedef unsigned char DGByte;
typedef DGArray<DGByte> DGByteArray;
Now you can use arrays with bytes like this, and save many memory space:
LOCAL tilemap[] AS DGByte
DIM tilemap[500][500]
Here is a GLB program to test the new types:
// --------------------------------- //
// Project: Testshort v2
//
ALLOWESCAPE TRUE
SETSCREEN 320, 240, 0
LIMITFPS 30
GOSUB TestShort
GOSUB TestByte
SHOWSCREEN
KEYWAIT
END
SUB TestShort:
// this way works ok
LOCAL map[] AS DGShort
DIM map[100]
map[0] = -32000
map[1] = 1234
map[2] = 32767
PRINT "Test short array", 0,0
PRINT "map(0) = " + map[0], 0,10
PRINT "map(1) = " + map[1], 0,20
PRINT "map(2) = " + map[2], 0,30
ENDSUB
SUB TestByte:
// this way works ok
LOCAL mapb[] AS DGByte
DIM mapb[100]
mapb[0] = 0
mapb[1] = 123
mapb[2] = 255
PRINT "Test byte array", 0,50
PRINT "mapb(0) = " + mapb[0], 0,60
PRINT "mapb(1) = " + mapb[1], 0,70
PRINT "mapb(2) = " + mapb[2], 0,80
ENDSUB
I hope you like it! :)
I kinda missed this, its a valuable insight into the inner workings of GLB I think.
Many thanks,
Ian
I love it but actually it's making too much trouble to use it yet D;
If I define a variable as a "char" I can't use the function "Readbyte" with it. Readbyte wants "DGNat", I want to use a char though :S
What about unsigned shorts, integers and longs?
"Byte" is not working for me :/ Only "Char".
And "unsigned char" isn't working too, it says "Syntax error".
Any idea? o:
In the last version, you can use numeric C types like: short (signed), WORD (unsigned short), char (signed), BYTE (unsigned char), double (floating 64 bits). These types are case sensitive: Byte isn't the same as BYTE.
LOCAL mapb[] AS BYTE // works ok
DIM mapb[100]
mapb[0] = 123
QuoteIf I define a variable as a "char" I can't use the function "Readbyte" with it. Readbyte wants "DGNat", I want to use a char though
I think you can use a integer(%) variable for READBYTE, and then assign the value to a BYTE variable using this: byteval = (num%). Curiously using () works ok =D.
Old thread, but I have a problem.
In this code:
TYPE TLevel
level_id%
map[] AS BYTE // Map array, 3 dimmensions, [y][z][x]
//map%[] // This works
ENDTYPE
I get this error:
user type is not defined : BYTE
Am I using it wrong, or do these new data types not work in TYPEs?
BTW, I'm using GLBasic 8.200
I think TYPES are declared in other header file where define BYTE is not accesible. Using "char" (signed byte) or "short" (signed word) works good, because they are C types.
Thanks! :booze:
You are probably right as 'char' seems to be working, and in my case, it should be good enough.
Oh, so close!
CONSTANT DIR_X AS char = 0
CONSTANT DIR_N AS char = 1
CONSTANT DIR_E AS char = 2
CONSTANT DIR_S AS char = 4
CONSTANT DIR_W AS char = 8
MazePart_AddSurface (TILE_0__, QUAD_XX, DIR_N + DIR_S + DIR_W + DIR_E)
gives me this error:
"LevelDraw.gbas"(589) warning : probably unassigned variable : DIR_N+ DIR_S + DIR_W + DIR_E
"LevelDraw.gbas"(589) error : variable is not explicitly defined : DIR_N+ DIR_S + DIR_W + DIR_E
You can't add 'chars' together?!?
Is it just a simple operator overload problem (ie: the '+' operator for char)?
[Edit]
But this seems to work (with the extra ()'s ):
MazePart_AddSurface (TILE_0__, QUAD_XX, (DIR_N) + (DIR_S) + (DIR_W) + (DIR_E))
Dont think Gernot has updated operators to use the new types yet
The problem is, that the precompiler handles them as TYPEs, thus it does not know about any operators other than =, <> and == (which is = in GLBasic, too)
No problem, I reverted back to using simple integers (%), which have less compatibility problems!
I was just trying to save a little memory, which is no big deal. (I have 4 integer arrays the same size, up to 50x50x10)
(I still may be able to, using integers, if I split the integer into 4 bytes by ANDing and ORing the bits I need in/out).
Thanks.
Could always use INLINE C