Re: changes fix #2

[martin f k. <ma...@ma...>]

also sprach Paul <ele...@ya...> [2004.11.05.0320 +0100]:
> Thought I'd better run the changes past you before I checked them in.=20

Ah, lovely fucking sourceforge crap. Sorry for my French there, but
they are highly annoying. I shall move this library to
alioth.debian.org soon.

> Looked at std::set and std::list, and the stl documentation for
> stuff on associative container concepts, sequence concepts etc.
> Not sure exactly what applies here, but I just added support for
> what looked ok.

Cool.

> always disregarded (at least at this stage).  It might in the
> future be helpful for insertion hints (like in set), but that is
> Future with a capital F. Not now.

I checked out insertion hints, but they are impossible to manage, as
the tree itself is not sorted across the contained elements, only
down a single root->leaf walk.

> I also removed the requirement for types to have
> default-construction. Previously for a type to work with kdtree++,
> it required a Type() style constructor.  This is unnecessary 	as
> demonstrated by set's constructor.

Could you elaborate on this, please?

> I readded the 'iterator' type.  set uses iterator instead of
> const_iterator in all of its definitions except for find() etc.
> Both are defined as the same type.  Scott Meyers (i think?)
> recommended not using const_iterator too much, as its a pain if
> you want to use it in some algorithms (which require iterators for
> whatever reason)... whatever, we should try and follow what others
> do - everything except find() uses iterator.

Mh, I would be interested in the reference. Scott Meyers says many
things, and I surely don't approve of all. If algorithms use
iterators without modifying the element pointed to, then it's a bug
in the algorithm, not in kdtree.

I also think that following the others is the way to go... unless
I have to implement all the whacko bugs and hacks the STL contains.

> I removed 'inline' declarations in front of method calls.  They
> are not required...

True, but I always like to make things explicit. In this case,
however, I am willing to go along without further discussion.

> I added a count_within_range() method for simply counting the
> number of items inside a range.  This is more efficient than doing
> a find if you just want a count, since the values aren't written
> to an output iterator.

Yeah, nice!

> I added this-> to some of the method calls. The STL does this,
> presumably to avoid confusing the calls with free-function calls.
> This is also probably why the STL 'reserves'
> function/method/variable names starting with __

Yes, precisely. Thanks for catching these.

> I am torn between american-ising the spelling, and not.=20

As I said, let's do both. I don't want the API to change right now.
Let's add optimize() to call optimise() and add some snide comment
in there about how British English is superior :)

> I renamed _M_meta to _M_header because they call it that in set<>.

Fine.

> I noticed rend() returned reverse_iterator(end()).  It should
> return begin().

Oops.

> - Improve operator=3D() and copy-constructor... theres a faster way
> of copying the tree across.

Certainly.

> - I looked at erase(), It would be nice to have a fast rebalancer
> like set, but right now thats asking too much.

Ha! Have a ball. I tore out my hair for two days on this. I may well
simply have overlooked it though.

If you figure something out, you know it's worth an ACM or IEEE
paper!

Again, Paul, thanks for your help.

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
"if i am occasionally a little overdressed, i make up for it by being
 always immensely over-educated."
                                                        -- oscar wilde