#168: Revamp mln::topo::internal::complex_data<D> --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup --------------------------+------------------------------------------------- Old description:

See source:branches/cleanup-2008/milena/mln/topo/complex.hh

* Store only the indices of adjacent faces in `complex_data<D>`: we don't really need actual faces there, and it costs a lot (memory, execution time, design complexity, etc.) * Then (or concurrently) simplify the design: use an array of array instead of an ad hoc type list. * The '''dynamic''' access(es) to the set of ''n''-faces of a complex (e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity! We should get rid of that. We could create an index at the creation of the complex, mapping dynamic dimension numbers to the corresponding (static) mixin/data.

New description: See source:branches/cleanup-2008/milena/mln/topo/complex.hh * Store only the indices ('''and the sign'''!) of adjacent faces in `complex_data<D>`: we don't really need actual faces there, and it costs a lot (memory, execution time, design complexity, etc.) * Then (or concurrently) simplify the design: use an array of array instead of an ad hoc type list. * The '''dynamic''' access(es) to the set of ''n''-faces of a complex (e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity! We should get rid of that. We could create an index at the creation of the complex, mapping dynamic dimension numbers to the corresponding (static) mixin/data. Comment (by levill_r): Update. -- Ticket URL: <https://trac.lrde.org/olena/ticket/168#comment:1> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.