libkdtree experiences and questions

[Paul Harris]

Note on the MS VC 2005, I've already come across and resolved some of
problems in my copy.

See below for notes


2008/11/11 Sylvain Bougerel <sylvain.bougerel.devel at gmail.com>

> On Tue, Nov 11, 2008 at 2:19 AM, Sam Hayne <Sam.Hayne at gmx.de> wrote:
> > Hello! :)
> >
> >
> > As the posting is a bit longer, a short summary:
> >
> >
> > =====================================
> > 1) compiler errors in VC2005 + solution
> > =====================================
> >
> > allocator.hpp:
> >
> > typedef confusion
> >
> > error: kdtree++/kdtree.hpp(95) : error C2059: syntax error : '<'
> >
> > solved by:
> > rename all _Node to e.g. _Node_Ab in this file starting from line 21:
> >
> > old: typedef typename _Node<_Tp> _Node;
> > new: typedef typename _Node<_Tp> _Node_Ab;
> >
>
> Okay, that's not nice, although I think that VC++ does not respect the
> standard here, we should still make the library portable.
>
> Just one question? why did you put _Ab as a suffix? A particular reason?
>

Its to do with multiple definitions of the same type, IIRC


>
> >
> > node.hpp:
> >
> > confusion:
> > reserved #defines (in windef.h) "near" and "far" used as variable names:
> > => rename near and far to something like near_N and far_N, starting from
> > line 337
> >
>
> Ah yeah, I remember dealing with something like that once. Hum, well,
> it should be changed too, I guess.
>

i don't remember seeing this one


>
> >
> >
> > iterator.hpp:
> >
> > error: error C2248: 'KDTree::_Iterator<_Val,_Ref,_Ptr>::operator *' :
> cannot
> > access private member declared in class
> 'KDTree::_Iterator<_Val,_Ref,_Ptr>'
> >
> > solved by:
> >
> > add "public:" in line 110:
> >
> >  template <typename _Val, typename _Ref, typename _Ptr>
> >    class _Iterator : protected _Base_iterator
> >    {
> >     public:    //added
> >       typedef _Val value_type;
> >       ...
> >
> >
>

I don't remember seeing this one either, maybe i did



>
> Ok I dunno weather it was g++ error of VC2005 error. But this rings a big:
> "DON'T DO THIS" bell in my mind.
>

>
>
> error C2247: 'KDTree::_Base_iterator::_M_node' not accessible because
> 'KDTree::_Iterator<_Val,_Ref,_Ptr>' uses 'protected' to inherit from
> 'KDTree::_Base_iterator'
>
> solved by:
>
> line 108: change "protected" to public
> old: class _Iterator : protected _Base_iterator
> new: class _Iterator : public _Base_iterator
>
> (may be really bad though..)
>

Same as above, ;-)
>
> >
> >
> > kdtree.hpp:
> >
> > comment away "__throw_exception_again;" in line 1175 => unknown
> identifier
> >
>
> Ohla, okay this is not nice: I think we should not use it cause it's
> pure libstdc++ stuff. It should be equivalent in most case to a
> simple:
>     throw;
> I'm gonna check why they use this in the library and not the above.
>


i've actually made a patch for this, using a class constructor+destructor to
do the cleanups automatically... thats what the try/catch/rethrow was for

i think i posted some of it on the mailing list just recently, its not in
the git repository yet


>
> >
> >
> > error in test_kdtree.cpp:
> >
> > warning C4003: not enough actual parameters for macro 'max'
> > error C2589: '(' : illegal token on right side of '::'
> > error C2059: syntax error : '::'
> >
> > caused by: *t.find_nearest(s,std::numeric_limits<double>::max()).first;
> >
> > Solved by: Undefine min/max previously defined in windows.h:
> >
> > #undef max;
> > #undef min;
> > triplet result =
> > *t.find_nearest(s,std::numeric_limits<double>::max()).first;
> >
> >
>

yeah i've come across this a bunch of times, windows.h #defines min and max
in some situations.  this is a common problem not just for kdtree

one solution is to #include kdtree before windows.h, which may not be
possible for your application.



>
> Urg, this is really ugly... can you tell us why you actually had
> "windows.h" included here? Did you added it for some reason, or does
> it get included by another file?
>
> test_kdtree.cpp should be plain standard... like it should not require
> platform specific headers...
>
> >
> >
> > change in triplet definition:
> >
> > struct triplet {
> >        typedef int value_type;
> >
> >        inline value_type operator[](size_t const N) const { return d[N];
> }
> >        inline bool operator==(triplet const& other) {
> >                return this->d[0] == other.d[0] && this->d[1] ==
> other.d[1]
> > && this->d[2] == other.d[2];
> >        }
> >
> >
> >        value_type d[3];
> > };
> >
> >
> >
> >
> >
> >
> >
> > ===========================
> > 2) Nearest neighbor search
> > ===========================
> >
> > One thing: As I was really unable to do a pointer comparison of the
> "duplet"
> > struct I chose to compare coordinates.
>
> Yeah, you won't actually get to do this in the nearest neighbor
> search, because, well, it compares by coordinates... I know it my
> sound patronizing here, but I don't know how to put it otherwise :)
>

i can add to this, that is why there is a find_exact(), so that you can find
*that* node, not just another node that has the same coordinates.


i'll stop here since the main thing i wanted to expand on was the VS 2005
stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/libkdtree-devel/attachments/20081111/73c7c1a9/attachment-0001.htm