oln 10.199: Minor fix.

Index: olena/ChangeLog from Damien Thivolle <damien@lrde.epita.fr> * oln/morpher/border_morpher.hh: Make compliant to g++-3.4. +2004-06-26 Damien Thivolle <damien@lrde.epita.fr> + * oln/convert/rgbnrgb.hh: Make compliant to g++-3.4. * oln/convert/rgbxyz.hh: Likewise. * oln/topo/dmap.hxx: Likewise. Index: olena/oln/morpher/border_morpher.hh --- olena/oln/morpher/border_morpher.hh Tue, 15 Jun 2004 20:36:26 +0200 odou_s (oln/u/15_border_mor 1.1 600) +++ olena/oln/morpher/border_morpher.hh Sun, 27 Jun 2004 23:19:20 +0200 thivol_d (oln/u/15_border_mor 1.1 600) @@ -117,13 +117,13 @@ const BehaviorType& be) : super_type(ima), width(width), be(be) { - be.adapt_border(ima, width + get_ima().border()); + be.adapt_border(ima, width + this->get_ima().border()); for (unsigned i = 0; i < image_id<exact_type>::dim; ++i) { - size_.nth(i) = get_ima().size().nth(i) + 2 * width; + size_.nth(i) = this->get_ima().size().nth(i) + 2 * width; dp_.nth(i) = -width; } - size_.border() = get_ima().size().border(); + size_.border() = this->get_ima().size().border(); } const coord width; ///< The width of the border. @@ -232,7 +232,7 @@ at(const point_type& p) { return const_cast<value_type &> - ( const_cast<SrcType &>(this->ima_)[p + get_dp()] ); + ( const_cast<SrcType &>(this->ima_)[p + this->get_dp()] ); } /*! @@ -243,7 +243,7 @@ const value_type at(const point_type& p) const { - return this->ima_[p + get_dp()]; + return this->ima_[p + this->get_dp()]; } /*! Perform a shallow copy from the decorated image of \a rhs @@ -329,7 +329,7 @@ const value_type at(const point_type &p) const { - return this->ima_[p + get_dp()]; + return this->ima_[p + this->get_dp()]; } /// Useful to debug. A vos checkin pour la 10.200 :) -- Damien Thivolle damien.thivolle@lrde.epita.fr

Je n'aime pas les borders morphers : - nom pas et explication pas trop (ni border_morpher, ni super_border_morpher). Dans la doc il est expliqué que le border_morpher "is a border morpher". - est-on sur de ce que ça fait (const cast) ? - il n'est pas normal qu'en incluant basics2D et border_morpher, on inclut tout integre. - ce code est long pour pas grand chose. - ce genre de fonction devrait peut-être être en interne.
wc border_morpher.hh 384 1251 11314 border_morpher.hh et 6 classes pour un outils.
Encore une fois je ne suis pas fan de la logique "un morpher pour une fonction". Le patch est ok. -- Niels

Niels van Vliet <van-vl_n@lrde.epita.fr> writes:
Je n'aime pas les borders morphers : - est-on sur de ce que ça fait (const cast) ? - ce code est long pour pas grand chose. - ce genre de fonction devrait peut-être être en interne.
wc border_morpher.hh 384 1251 11314 border_morpher.hh et 6 classes pour un outils.
Encore une fois je ne suis pas fan de la logique "un morpher pour une fonction".
Le patch est ok.
Oui le "const cast" est nécessaire, oui le code est long pour pas grand chose... Ce n'est pas seulement le border morpher que tu remets en cause mais tous les morphers (tu verras que les autres ont les mêmes problèmes). A ces problèmes on peut ajouter (et non l'un des moindres) le typage très long que doit écrire l'utilisateur d'un morpher qu'il ne veut pas constant. On ne veut pas utiliser "un morpher pour une fonction": juste quand l'image morphée est une vue directe de l'image. On peut discuter de: - comment simplifier l'écriture des morphers ? (en sachant que si on a 3 classes par morphers (super, const et non const), c'est pour régler le problème du const et on ne peut pas vraiment y échapper). - comment simplifier l'utilisation des morphers non constants ? (i.e. typage trop long) - quand utiliser un morpher à bon escient ? (à mon avis partout ou le résultat est une vue directe de l'entrée). Pour les autres problèmes cités (l'inclusion d'integre par exemple), tu as raison et je corrigerai. -- Simon Odou simon@lrde.epita.fr
participants (3)
-
Damien Thivolle
-
Niels van Vliet
-
Simon Odou