25 Sep
2008
25 Sep
'08
1:29 p.m.
#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.