
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Changes (by levill_r): * status: new => assigned * owner: Olena Team => levill_r Old description:
* Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions:
- rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file.
Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound.
(And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons).
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2377 and r2380.) * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions: - rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file. Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound. (And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). Comment: Update the to-do list. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:3> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.