• bobef (17/17) Feb 04 2005 I do some win32 programing recent days and I've come to a problem, that
• zwang (2/19) Feb 04 2005 You may try gc.addRoot/removeRoot/addRange/removeRange.
• Daan Oosterveld (16/33) Feb 04 2005 Hi,

bobef <bobef paintballforce.com> writes:

I do some win32 programing recent days and I've come to a problem, that 
I believe is common for everyone who does win32 in D. The whole win32 
policy is casting pointers to integers and back, which is pain with the 
garbage collector... There are cases (owner drawn menus, tree controls, 
more...) where you have to write something in the long value of a an 
item and this is done in mind this long will be address of a structure 
or something but if you do in D GC will move your things somewhere and 
the address in item will not be correct, resulting most probably - 
crash. I solved this with associative array where needed. Because my 
data is in xml form, I write .toHash() of my xml nodes in the lParam and 
then I search back for this hash in the xml tree (I don't really know 
what is "hash"... I hope it is unique and it doesn't change... it works 
for the moment). But this is kind-a .... well slow... although user will 
  never notice and my xml trees don't contain more than 20-30-40 
children I don't like this way. Has anyone came to a better solution? 
It's would be very cool if it was possible to "lock" the objects so the 
GC won't move them...

zwang <nehzgnaw gmail.com> writes:

bobef wrote:
 I do some win32 programing recent days and I've come to a problem, that 
 I believe is common for everyone who does win32 in D. The whole win32 
 policy is casting pointers to integers and back, which is pain with the 
 garbage collector... There are cases (owner drawn menus, tree controls, 
 more...) where you have to write something in the long value of a an 
 item and this is done in mind this long will be address of a structure 
 or something but if you do in D GC will move your things somewhere and 
 the address in item will not be correct, resulting most probably - 
 crash. I solved this with associative array where needed. Because my 
 data is in xml form, I write .toHash() of my xml nodes in the lParam and 
 then I search back for this hash in the xml tree (I don't really know 
 what is "hash"... I hope it is unique and it doesn't change... it works 
 for the moment). But this is kind-a .... well slow... although user will 
  never notice and my xml trees don't contain more than 20-30-40 children 
 I don't like this way. Has anyone came to a better solution? It's would 
 be very cool if it was possible to "lock" the objects so the GC won't 
 move them...

You may try gc.addRoot/removeRoot/addRange/removeRange.

Daan Oosterveld <daan.oosterveld home.nl> writes:

Hi,

Create a mapping between the hash (or preferbly an unique number) and D 
adresses. When your object is moved the address in the address in the 
mapping is updated by the GC and you van write:

your_object_type *[uint] mapping;
ptr_to_your_object = mapping[ unique_hash_or_number ];

It is not a great solution, but it's faster.

Hashes are nog unique. They are a solution to put objects in equal 
groups so they can be found faster. A Hashtable is made up of Buckets. 
Every object with the same hash will be put in the same Bucket. If you 
then want to find a object a hash value is created with .toHash and the 
Bucket matching the hash is searched through. With 30 to 40 objects this 
should be a problem but with more hashes could be the same and you will 
end up with a bit of a problem ;)

Daan Oosterveld


bobef schreef:
 I do some win32 programing recent days and I've come to a problem, that 
 I believe is common for everyone who does win32 in D. The whole win32 
 policy is casting pointers to integers and back, which is pain with the 
 garbage collector... There are cases (owner drawn menus, tree controls, 
 more...) where you have to write something in the long value of a an 
 item and this is done in mind this long will be address of a structure 
 or something but if you do in D GC will move your things somewhere and 
 the address in item will not be correct, resulting most probably - 
 crash. I solved this with associative array where needed. Because my 
 data is in xml form, I write .toHash() of my xml nodes in the lParam and 
 then I search back for this hash in the xml tree (I don't really know 
 what is "hash"... I hope it is unique and it doesn't change... it works 
 for the moment). But this is kind-a .... well slow... although user will 
  never notice and my xml trees don't contain more than 20-30-40 children 
 I don't like this way. Has anyone came to a better solution? It's would 
 be very cool if it was possible to "lock" the objects so the GC won't 
 move them...