<br><br><div class="gmail_quote">2008/11/13 martin f krafft <span dir="ltr"><<a href="mailto:madduck@debian.org">madduck@debian.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
also sprach Paul Harris <<a href="mailto:paulharris@computer.org">paulharris@computer.org</a>> [2008.11.13.1302 +0100]:<br>
<div class="Ih2E3d">> that way, the same code will "scale up" from an 8 bit microcpu up<br>
> to the 64 bit gorillas<br>
<br>
</div>Yes, so the question is whether we want/need this. Once you start to<br>
serialise/archive/save kdtrees, you are making it unnecessarily<br>
difficult. unsigned int should be enough for everybody, no? :)<br>
</blockquote><div><br>Maybe, maybe not. I would love to be able to build a kdtree and store it in a vector<> rather than heaps of linked pointers to small allocated nodes... if that happens then we would be serializing vectors, whose size is defined by size_t<br>
<br>But, I agree with your arguments, at this point we don't need anything bigger than an unsigned int (AFAIK), so why jump to size_t<br><br>I suppose the question is would we ever want to move to size_t ? If so then we may as well make the leap now. kdtree already currently uses size_t in a lot of places, so we technically would be going backwards if we switched to unsigned int.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
(or maybe this should be a #define-able option?)<br><br></blockquote></div><br>Heh... maybe, but I'd rather just give people the choice if there is evidence that someone would ever want to make that choice<br><br>