CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

On 01/30/2013 11:39 AM, Philipp Moeller wrote:
> Cody 
> Rose<>
>   writes:
>
> > Hello,
> >
> > With CGAL 4.1 I am unable to use the Nef_polyhedron_3 package with
> > BOOST_RESULT_OF_USE_DECLTYPE defined. I am using:
>
> You have to define BOOST_RESULT_OF_USE_DECLTYPE because your compiler
> does not implement a fully conforming decltype. (AFAIK, the only
> compiler that currently does is clang 3.2).
I guess you meant you can't define BOOST_RESULT_OF_USE_DECLTYPE ?

Sebastien.

> > CGAL 4.1
> > the CORE numeric library, along with its dependencies (GMP etc)
> > Boost 1.47
> > Visual Studio 2010
> >
> > The problem does *not* appear in CGAL 3.9.
>
> CGAL 3.9 didn't use result_of. That's why you don't see the problem.
>
> > The following code reproduces the problem for me:
> >
> > // This is the problematic define.
> > #define BOOST_RESULT_OF_USE_DECLTYPE
> >
> > #include<vector>
> >
> > #include<boost/range/algorithm.hpp>
> > #include<boost/range/adaptors.hpp>
> >
> > #include<CGAL/Cartesian.h>
> > #include<CGAL/CORE_Expr.h>
> > #include<CGAL/Nef_polyhedron_3.h>
> >
> > typedef CORE::Expr                        NT;
> > typedef CGAL::Cartesian<NT>                 K;
> > typedef CGAL::Nef_polyhedron_3<K>         nef_polyhedron_3;
> >
> > int main() {
> >      std::vector<int>  a(0, 3);
> >      a[0] = 1;
> >      a[1] = 2;
> >      a[3] = 3;
> >      std::vector<int>  b;
> >
> >      // With BOOST_RESULT_OF_USE_DECLTYPE defined, the following line
> > causes an error.
> >      nef_polyhedron_3 foo;
>
> This is because MSVC decltype triggers instantiation prematurely.
>
> >      // Without BOOST_RESULT_OF_USE_DECLTYPE defined, the following
> > line causes an error.
>
> This is because built-in lambdas require a decltype based result_of.
>
> >      boost::copy(a | boost::adaptors::transformed([](int x) { return x
> > * 2; }), std::back_inserter(b)); return 0; }
>
> It would be nice if both worked together, even with a broken
> decltype. If I remember correctly there was a work-around involving two
> Type_equality_wrappers when instantiating kernels.