Arrays of Types - Position in Memory?
BlitzMax Forums/BlitzMax Programming/Arrays of Types - Position in Memory?
| ||
If I have something like this :Type tMyType Field x:Int Field y:Int Field z:Int End Type ..And I make an array of them, say ten elements long. Can I guarantee that it's all in one contiguous block of memory? In other words, if I want to pass the array to a DLL or Windows API function, I can just point to MyArray[0] and it will find the 120 bytes which make up my array as they should be? Is this safe practice or do I need to make a bank and copy the contents of array and fields into that? |
| ||
| No this can't be guaranteed, only the pointer references to them are in a continous block. If you really need them as one block for some reason, you will need to use banks. Using them with external won't work anyway, BM objects have an overhead you do not see in your type declaration (8 bytes if I remember correctly) which is why straight using the array won't be of much use. |
| ||
| I know there's a header in the type declaration, but I thought that was per type, not per instance. On reflection, I have no idea why I thought that, as it's not very logical. Max's insistence on doing everything in a non-standard way makes it a real pain in the butt to work with other languages. |
| ||
| Not only with other languages :( Its internal inconsistencies make it even a pain to create modules for itself ... |
| ||
| Saying its a pain might be over stating it a bit, however it does need its inter-language interfacing beefing up, a great deal of external libraries not to mention os api's use c structs and dealing with them can be a nightmare being able to use C objects would be a dream I've lost count of the numbe of times I've had to do loads of tiny seperate get and set functions like this (real tedious work!)
extern "C" int GetSomeParam(aCobject* e, int op, int index)
{
return e->GetSomeParam(op, index);
}
I've found the debugger to be fairly poor when dealing with external libs, often showing the error line a random distance from the actual function call that caused the problem, some kind of itergration with gdb would be nice as an alternitive. Mark seem to have a pathalogical lothing of including C structs in Max (or at least thats the impression I get) which is a real shame... Which is a real shame, not only for us, but for brl sales. |
| ||
| Not only with other languages :( Its internal inconsistencies make it even a pain to create modules for itself ... Yes, I'm sure you're right, though I haven't done so much of that personally. Mark seem to have a pathalogical lothing of including C structs in Max (or at least thats the impression I get) which is a real shame... I get the same impression, and I don't understand why. It's common for non-C languages to use standard C Structs for compatiblity with external libraries, WinAPI, mixing languages, etc. PureBasic does it, IBasic does it. And it's even more infuriating since BMax is inherently tied into GCC and allows you to include C code in directly into BMax projects. Neither IB or PB is tied in this way, they just do it make it a more versatile language. I find myself doing the same thing with getters and setters, but there's an overhead to doing things this way. I try to hardcode the calls to the getters and setters and combine all fields of a struct into additional full-struct getters and setters to minimize the overhead when all fields are required, but it's still an incredible waste of time having to code it all for every struct and the end result is - no matter how small the margin - slower than it needs to be. |
| ||
| Didn't Mark already propose an implementation of C structures in BlitzMax and then never do anything about it? |
| ||
| Can't remember. It was just requested about 50 times now, like full ENUM support as well. |
| ||
| You would have an array of MyType pointers, and those pointers would be in sequence in memory, but what they point TO could be totally randomly scattered. That is, unless, you create a memory bank, put your data in the bank in sequential order, and then `hardwire` the array to point exactly to the offsets in the bank where each object starts. |
| ||
| Right, but with an array of ints, I can assume that the ints are all aligned in memory, right? I know that I have to point to the index of the first element in the array, not a variable pointer, but all subsequent elements are aligned after it in a block of contiguous memory, right? |
| ||
| using a bank is one method I use, but working out all the correct offsets is a pain I end up writing little c functions to calculate it for me, but again, a pain and a needless waste of time, somthing that a pro quality compiler should be able to do automatically It would also make using libs less error prone as errors are less likely to creep in Maybe when we all get sick of waiting for Mark and one of us gets the time there may be a way of modifying bmk to preprocess code, but then I dont like the idea of using a none standard bmk... |
| ||
| "Mark seem to have a pathalogical lothing of including C structs in Max (or at least thats the impression I get) which is a real shame..." Me too. Could make life so much simpler, which is what I thought Max was all about. |
| ||
| gee mark hope I havent upset you maybe the word pathalogical was a bit strong.... |
| ||
| An array of Int's is all aligned in memory, but an array of custom types which have Int fields is not. |
| ||
| Slightly off topic, but the concept of arrays of types facinates me for one particular aplication. I would be *VERY* grateful if some kind soul would show an example of an array definition of a number of instances of the same type, and how to refer to them. Thanks |
| ||
Strict
Type Ttest
Field x
Function create:TTest(x:Int)
Local my:TTest = New Ttest
my.x:Int = x
Return my
End Function
End Type
Local myarray:TTest[5]
For Local x = 0 To 4
myarray[x]=Ttest.create(x)
Next
For Local x = 0 To 4
Print myarray[x].x
Next
|
| ||
| Thanks, Tony, once again very prompt and helpful! |
   |