A question for you all: size_t or unsigned int

[Sylvain Bougerel]

On Thu, Nov 13, 2008 at 9:48 PM, Paul Harris <paulharris at computer.org> wrote:
>
>> I don't see the benefit of asking the user to include only that
>> file. I am also not sure about the typedef. That's nicer and
>> cleaner than a define, but I think that
>>
>> #ifndef KDTREE_SIZE_T
>> #define KDTREE_SIZE_T unsigned int
>> #endif
>>
>> in a header file included by all other header files, is a better way
>> forward. If the user now needed to override (which we assume is the
>> exception), s/he'd just
>>
>> #define KDTREE_SIZE_T unsigned long long
>> #include <kdtree++/kdtree.hpp>
>>
>> If s/he doesn't #define, then the default is used.
>
> good suggestion... ok done.
>
> Hope you won't be pissed, but I'd like to follow the STL's lead and use
> size_t as the default.  Plus, size_t has been what we've been using in
> 0.6.2.
>

Yes, I like that decision too.

> You pointed out that platform differences may make serialization difficult
> between platforms, but that is the case even for std::vectors...
>

I think neither size_t nor unsigned int are required to fit any size,
so I don't think portability is an argument in favor of any of them :)

> Attached are 3 patches, you clone the git repo and then use "git am" to
> apply each one in turn (Martin already knows this, I didn't)
>
> The next thing to do is fix the bug shown via test_hayne, and I think i've
> seen another bug in find() where it may return a random (or nearby) point
> when it can't find the point at all.  I'll write a test case for it
> tomorrow.
>
> If you want to have a look, please go ahead.  If people are happy with what
> i've done, i'll push it to the repository.

If you push, please update the version number and tag the tree. You
might want to go for a 0.7 but... I don't see what's the rush, like
you say, there is not difference in the API, so just please tag for
0.6.3: remember we can release a tarball of the source for those who
don't have git and still want to beneficit of library. I think those
are the majority of user of the library. Therefore, we need a new
version number.