No they don't work the same as C++. They are derived from structures built in C++, however as dmoc said, they always have a header, which we have no control over. C++ doesn't explicitly introduce any sort of header to user defined structures.
Types in bmax are not well suited when calling external functions that only expect one element too. After some troubleshooting and searching the forums, I found you can use the varptr 'operator' with the first field of your type definition to get the actual memory address of the instance in memory (ugly). Defining arrays within a Type are not part of the struct, but also a reference type, so you must declare padding bytes to achieve the same thing.. Gets a little ugly when you have larger arrays.
If you are dealing with arrays of Types, you are out of luck. In order to better interface to external APIs, it is a requirement that bmax support a "C" style structure type, or it will become a bottle neck.
Edit: and to clarify.
Types in bmax are always reference types, and not 'value' types.
Assuming a base address of 0x00000000, in memory this should look like the following, to match a C++ or C style structure:
1st element
0x00000000 x
0x00000004 y
2nd element
0x00000008 x
0x0000000C y
3rd element
0x00000010 x
0x00000014 y
Notice, it is a continuous block of memory.
However, with bmax's object type, this might look like:
1st element
0x00000000 header data
0x00000010 x
0x00000014 y
2nd element
0x00000050 header data
0x00000060 x
0x00000064 y
3rd element
0x00001240 header data
0x00001250 x
0x00001254 y
etc...
It is references to objects elsewhere in memory, so before passing to an external function, as dmoc said, the data must be packed as my first example of memory layout, using peeks, pokes, mem-copies, etc.
Types in bmax are not well suited when calling external functions that only expect one element too. After some troubleshooting and searching the forums, I found you can use the varptr 'operator' with the first field of your type definition to get the actual memory address of the instance in memory (ugly). Defining arrays within a Type are not part of the struct, but also a reference type, so you must declare padding bytes to achieve the same thing.. Gets a little ugly when you have larger arrays.
If you are dealing with arrays of Types, you are out of luck. In order to better interface to external APIs, it is a requirement that bmax support a "C" style structure type, or it will become a bottle neck.
Edit: and to clarify.
Types in bmax are always reference types, and not 'value' types.
CType TSomeStruct Field x:Int, y:Int End CType Local myarray:TSomeStruct[100]
Assuming a base address of 0x00000000, in memory this should look like the following, to match a C++ or C style structure:
1st element
0x00000000 x
0x00000004 y
2nd element
0x00000008 x
0x0000000C y
3rd element
0x00000010 x
0x00000014 y
Notice, it is a continuous block of memory.
However, with bmax's object type, this might look like:
1st element
0x00000000 header data
0x00000010 x
0x00000014 y
2nd element
0x00000050 header data
0x00000060 x
0x00000064 y
3rd element
0x00001240 header data
0x00001250 x
0x00001254 y
etc...
It is references to objects elsewhere in memory, so before passing to an external function, as dmoc said, the data must be packed as my first example of memory layout, using peeks, pokes, mem-copies, etc.