size_t, more info

[Sylvain Bougerel]

On Sun, Nov 16, 2008 at 12:45 PM, Paul Harris <paulharris at computer.org> wrote:
> Hi all,
>
> I went looking for some info on when you should use size_t and when you
> should use unsigned, because I didn't really know the pros and cons of each
> approach...
>
> Here is some reading:
> http://www.embedded.com/columns/programmingpointers/200900195
> http://www.embedded.com/columns/programmingpointers/201803576
> http://www.embedded.com/columns/programmingpointers/202404371
> http://www.embedded.com/showArticle.jhtml?articleID=204700432
>
> it gives a good explanation of things
>

Yeah, great article.

> i think we should use size_t for things like size() and count_within_range()
> (even if for no other reason than to follow the STL) but i'm still not clear
> on what we should use for the dimension size.  to me, it doesn't seem to
> make any difference, which is why i think we should just use size_t for
> everything.
>

I think we should use size_t too. And in particular std::size_t. Just
for the sake a standardization :) (because we gonna include cstddef).
There is one little thing that might cause a problem. But ppl in boost
have already fixed that little annoyance with some version of vc++
prior to vc2005 apparently:

  #if defined _MSC_VER && _MSC_VER <= 1200
  namespace std
  {
      using ::ptrdiff_t;
      using ::size_t;
  }

Now we can put this in the code too.


As for the dimension we should keep size_t (since it's scalling to
what the CPU register are using, we are garentied that the dimension
type will always be an efficient one). I'm keen on seeing a:

  typedef std::size_t dimension_type;

above the Kd-tree declaration. This is mainly for clarity in the code,
and also because we might have to make the Dimension a functor, for
those who want dynamic dimension specification, one day.

I'll be waiting for your answers,

Cheers