CGAL users discussion list

[Marc Glisse <>]

On Thu, 26 Nov 2015, Laurent Rineau (CGAL/GeometryFactory) wrote:

> Le Wednesday 25 November 2015 18:52:03 Marc Glisse a ?crit :
> > On Wed, 25 Nov 2015, Bart Vermeulen wrote:
> > > I'm trying to use c++11 threads with a Kd_tree.
> > >
> > > I have a function which takes a Kd_Tree as input:
> > >
> > > void foo (Tree const & tree, ...) {
> > >
> > >    // Do something
> > >
> > > }
> > >
> > > Than I try to pass the function to a std::thread construction:
> > >
> > > std::thread thethread(foo, tree, ...);
> > >
> > > This gives me an error telling me that the constructor Kd_tree(const Tree&
> > > tree) is private.
> > >
> > > The std::thread construction requires all parameters to be move
> > > constructible, but why is this construction private for a Kd_tree?
> > >
> > > Is there some way around this issue?
> >
> > http://en.cppreference.com/w/cpp/utility/functional/reference_wrapper
> >
> > On Wed, 25 Nov 2015, Bart Vermeulen wrote:
> > > I solved the issue passing a pointer to the tree, instead of a reference.
> > >
> > > Still I think it's strange that the copy construction is made private in
> > > Kd_tree.
> >
> > How often do you actually want a copy of a kd-tree? If you are doing the
> > copy by accident, or because you don't know the right syntax, it is good
> > that you get some error about it.
>
> But should not the CGAL develop try to allow the move constructor, when the
> copy constructor is disabled?

Yes, sure, feel free to implement it (this private, not-quite-copy 
constructor (Tree != Self) that doesn't actually copy the data is a bit 
strange, by the way). But in the OP's case, it seems much more likely that 
using a reference is the best option. Also, moving would require passing 
an explicit std::move(tree).

About Kd_tree, if we are going to add features, I'd be much more 
interested in functions to add or remove points (mostly remove, actually) 
without having to recompute the whole data-structure (even if subsequent 
searches have sub-optimal complexity).

--
Marc Glisse