CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

schrodingersnewcat wrote:
> Okay, I've done some more investigating.  I got valgrind to work on an
> executable compiled using intel's c++ compiler (g++ compiled code kept
> complaining about -froundingmath when I used valgrind, even though I used
> the switch during compile as I should).  
>
> So what I found out was this:  There appear to be no memory leaks, however
> the allocated memory is huge.  For 20000 identity transformations the
> allocated memory was around 2.7 GB.  Is there a reason that asking for level
> 3 optimization or other compiler switches might cause the memory to grow
> like this?
>
> Thanks for any help.
>
> --
> View this message in context: 
> http://cgal-discuss.949826.n4.nabble.com/Memory-Management-with-Nef-polyhedra-tp3404480p3409822.html
> Sent from the cgal-discuss mailing list archive at Nabble.com.
Exact_predicates_exact_constructions_kernel implements a filtering 
mechanism maintain a DAG of the cascaded constructions.
Each transformation creates a note in the DAG.

When the answer to a predicate can be certified using approximated
constructions, the DAG does not change. When approximations are
not sufficient to conclude (what we call a filter failure), a traversal
of the DAG is made and the corresponding path is simplified and replaced
by the corresponding exact value (memory consumption usually decreases).

In general it is not a good idea to use this kernel if you plan to do 
cascaded constructions.

If gmp is available on your machine, you can try using 
CGAL::Cartesian<CGAL::Gmpq> (reference counted objects with Gmpq as
number type) or CGAL::Cartesian<CGAL::Lazy_exact_nt<CGAL::Gmpq> >
(reference counted objects with CGAL::Lazy_exact_nt<CGAL::Gmpq> which is
a filtered number type).

S.