From: Matt L. <ml...@le...> - 2004-09-23 20:59:56
|
Does anyone object to the replacement of the cast_to_*() functions in vsol and vtol with dynamic_cast? I know this issue has come up before, and I think the decision was to allow RTTI outside of the "core". The problem we are having with the cast_to_*() functions is that each class must know about all of its subclasses. If we wish to add a new derived classes we must add a cast_to_*() function to the parent. This is a problem, for example, when we try to create a local library of classes that extend vsol. As a result, we might attempt to update vsol and vtol to use dynamic_cast unless anyone can see a reason why this would be a bad idea. Thanks, Matt Leotta |
From: Peter V. <Pet...@es...> - 2004-09-23 21:54:26
|
> Does anyone object to the replacement of the cast_to_*() functions in > vsol and vtol with dynamic_cast? Well, it could make moving vsol and vtol to the core more difficult. And I would like to see it move in the near future ;-) -- Peter. |
From: Matt L. <ml...@le...> - 2004-09-24 13:28:37
|
> > Does anyone object to the replacement of the cast_to_*() functions in > > vsol and vtol with dynamic_cast? > > Well, it could make moving vsol and vtol to the core more difficult. > And I would like to see it move in the near future ;-) The Zurich meeting notes file says: "Level 1 libraries should not require RTTI. High level libraries may use RTTI." If vsol and vtol move to the "core" they would not be level 1 libraries since they depend on several level 1 libraries. So this would not be in violation of the previous decision to keep RTTI out of level 1 core. -Matt Leotta |
From: Amitha P. <pe...@cs...> - 2004-09-24 13:41:37
|
On Thu 23 Sep 2004, Matt Leotta wrote: > Does anyone object to the replacement of the cast_to_*() functions in > vsol and vtol with dynamic_cast? You did not ask for positive responses, but I'll offer one anyway. I support using dynamic_cast in vsol and vtol. I don't think the original reasons for not using RTTI really hold any more. Besides, RTTI is a mandatory part of the C++ language. I believe that all modern compilers implement it quite efficiently. Amitha. |
From: William A. H. <bil...@ny...> - 2004-09-24 14:46:25
|
Just something to think about, all compilers do implement it, but it remains a non-default option for many of them. You will want to make sure that you figure out the flag to turn it on, and make sure you force it to be on by default in the cmake files for vxl. -Bill At 09:41 AM 9/24/2004, Amitha Perera wrote: >On Thu 23 Sep 2004, Matt Leotta wrote: >> Does anyone object to the replacement of the cast_to_*() functions in >> vsol and vtol with dynamic_cast? > >You did not ask for positive responses, but I'll offer one anyway. I >support using dynamic_cast in vsol and vtol. > >I don't think the original reasons for not using RTTI really hold any >more. Besides, RTTI is a mandatory part of the C++ language. I >believe that all modern compilers implement it quite efficiently. > >Amitha. > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Peter V. <Pet...@es...> - 2004-09-25 15:42:38
|
I just think of one unfortunate side effect of using dynamic_cast<*> instead of cast_to_*(): While one can write void f(vsol_curve_2d_sptr c) { vsol_line_2d_sptr l = c->cast_to_line(); } one cannot write void f(vsol_curve_2d_sptr c) { vsol_line_2d_sptr l = dynamic_cast<vsol_line_2d*>(c); } and it is necessary to write void f(vsol_curve_2d_sptr c) { vsol_line_2d_sptr l = dynamic_cast<vsol_line_2d*>(c.ptr()); } which is not so nice since using .ptr() on smart pointers actually circumvents the smartness of the pointer, which could be dangerous (not in this context, but once "ptr()" starts to be used often enough, people will start using it in other situatons as well :-{ -- Peter. |
From: Matt L. <ml...@le...> - 2004-09-27 15:01:42
|
> I just think of one unfortunate side effect of using dynamic_cast<*> > instead of cast_to_*(): > > While one can write > void f(vsol_curve_2d_sptr c) { > vsol_line_2d_sptr l = c->cast_to_line(); > } > one cannot write > void f(vsol_curve_2d_sptr c) { > vsol_line_2d_sptr l = dynamic_cast<vsol_line_2d*>(c); > } > and it is necessary to write > void f(vsol_curve_2d_sptr c) { > vsol_line_2d_sptr l = dynamic_cast<vsol_line_2d*>(c.ptr()); > } > which is not so nice since using .ptr() on smart pointers actually > circumvents the smartness of the pointer, which could be dangerous > (not in this context, but once "ptr()" starts to be used often enough, > people will start using it in other situatons as well :-{ > > > -- Peter. I agree that this is a problem, but it's a problem related to the smart pointer and goes beyond the use of dynamic_cast. The same problem occurs when upcasting smart pointers. For example: one cannot write void f(vsol_line_2d_sptr l) { vsol_curve_2d_sptr c = l; } and it is necessary to write void f(vsol_line_2d_sptr l) { vsol_curve_2d_sptr c = l.ptr(); } This problem is somewhat handled in vgui for tableau. Tableau classes create smart pointers that are a subclass of the smart pointers of their parent class. The result is a parallel inheritance hierarchy of smart pointers that mimics that of the classes that they point to. Unfortunately, this requires the use of special vgui_tableau_new classes to construct these smart pointers. This approach is not widely used throughout the rest of VXL, and admittedly wouldn't help with down casting. The point is we already have this unfortunate need for .ptr() even without the dynamic_cast :( -Matt Leotta |
From: Amitha P. <pe...@cs...> - 2004-09-27 15:24:54
|
On the topic of smart pointer assignment: The simplest solution to this is, of course, member templates. Does anyone have a good idea of which compilers don't support this simple member template? Other solutions and workarounds: [ assuming a typedef "pointer_type" in vbl_smart_ptr<T> that returns T* ] 1. Completely within the VXL restrictions: template<class OutT, class InT > OutT sptr_assign( OutT, InT in ) { return OutT( in.ptr() ); } template<class OutT, class InT > OutT sptr_dynamic_cast( OutT, InT in ) { return OutT( dynamic_cast<typename OutT::pointer_type>(in.ptr()) ); } used as vtol_line_2d_sptr line; vtol_curve_2d_sptr curve; curve = sptr_assign( vtol_curve_2d_sptr(), line ); line = sptr_dynamic_cast( vtol_line_2d_sptr(), curve ); 2. With explicit template parameters for template *functions*: template<class OutT, class InT > OutT sptr_assign( InT in ) { return OutT( in.ptr() ); } template<class OutT, class InT > OutT sptr_dynamic_cast( InT in ) { return OutT( dynamic_cast<typename OutT::pointer_type>(in.ptr()) ); } used as vtol_line_2d_sptr line; vtol_curve_2d_sptr curve; curve = sptr_assign<vtol_curve_2d_sptr>( line ); line = sptr_dynamic_cast<vtol_line_2d_sptr>( curve ); 3. With simple member templates: Add the member templates in vbl_smart_ptr template<class U> vbl_smart_ptr<T>( U in ) : ptr_( in.ptr() ) { ref(ptr_); } template<class U> vbl_smart_ptr<T>& operator=( U in ) { ... } then vtol_line_2d_sptr line; vtol_curve_2d_sptr curve; curve = line; but dynamic cast would need solution (1) or (2) above. Amitha. |
From: Peter V. <Pet...@es...> - 2004-09-27 18:24:13
|
> one cannot write > void f(vsol_line_2d_sptr l) { > vsol_curve_2d_sptr c = l; > } > and it is necessary to write > void f(vsol_line_2d_sptr l) { > vsol_curve_2d_sptr c = l.ptr(); > } > > The point is we already have this unfortunate need for .ptr() even > without the dynamic_cast :( Not when using cast_to_*: void f(vsol_line_2d_sptr l) { vsol_curve_2d_sptr c = l->cast_to_curve(); } |
From: Peter V. <Pet...@es...> - 2004-09-24 14:04:10
|
> "Level 1 libraries should not require RTTI. High level libraries may > use RTTI." > > If vsol and vtol move to the "core" they would not be level 1 libraries > since they depend on several level 1 libraries. So this would not be in > violation of the previous decision to keep RTTI out of level 1 core. All right. No problem, then, I presume. |
From: Peter V. <Pet...@es...> - 2004-09-24 15:00:17
|
Actually, I propose to leave all cast_to_* methods in, but inside an #if !VCL_HAS_DYNAMIC_CAST , for backward compatibility. Possibly (but not necessarily, since that makes code less readable) also the dynamic-cast uses could be "bi-implemented" this way, e.g.: void f(vsol_curve_2d_sptr c) { #if VCL_HAS_DYNAMIC_CAST vsol_line_2d_sptr l = dynamic_cast<vsol_line_2d*>(c.ptr()); #else vsol_line_2d_sptr l = c->cast_to_line(); #endif if (l) { ... } } Or maybe somebody could come up with a unified approach that avoids those "#if"s in user code? -- Peter. |
From: Peter V. <Pet...@es...> - 2004-09-26 20:23:53
|
I must say I don't see the purpose of the new vsol_digital_curve_2d class. Digital geometry already exists -- it was placed in a separate library (vdgl) but that library conceptually belongs to vsol. The main difference between the old vdgl_digital_curve and the new vsol_digital_curve_2d is the fact that the new one uses refcounted vsol_point_2d's as guide points instead of pairs of double. Which makes it less useful for dense points (which is the main use of vdgl). But with sparse guide points, I don't see a difference between the new vsol_digital_curve_2d and the class vsol_polyline_2d. Hence my question: do we need this new class? It is just causing confusion with the existing digital geometry in vdgl (e.g., by its replacement of cast_to_digital_curve()). -- Peter. |
From: Matt L. <ml...@le...> - 2004-09-27 16:06:27
|
On Sun, 2004-09-26 at 16:23, Peter Vanroose wrote: > I must say I don't see the purpose of the new vsol_digital_curve_2d class. > Digital geometry already exists -- it was placed in a separate library > (vdgl) but that library conceptually belongs to vsol. > > The main difference between the old vdgl_digital_curve and the new > vsol_digital_curve_2d is the fact that the new one uses refcounted > vsol_point_2d's as guide points instead of pairs of double. > Which makes it less useful for dense points (which is the main use of vdgl). The guide points in vdgl are actually more that pairs of doubles. They are edgels, which are pairs of doubles with two more doubles for gradient and orientation (4 doubles at each point). This is really targeted towards use in edge detection. In addition these points are stored in edgel chains, which are maintained by an interpolator object, which is contained within a vdgl_digital_curve. So you have dig through three layers of abstraction if you want to get to the actual point set. The intent of the vsol_digital_curve_2d was to remove the additional edge detection information and allow more direct access to underlying points while still allowing for the concept of a continuous structure via interpolation. > > But with sparse guide points, I don't see a difference between the new > vsol_digital_curve_2d and the class vsol_polyline_2d. The current difference is that vsol_digital_curve_2d supports interpolation at an arbitrary floating point index along the curve. Currently interpolation is linear, but we would like to find a way to abstractly allow a choice of interpolation function with out all the mess of the extra layers in vdgl. There is also some additional functionality to find the closest point to the curve and to split the curve at an arbitrary point. Currently vsol_polyline_2d is a simplification of vsol_digital_curve_2d. > > Hence my question: do we need this new class? It is just causing > confusion with the existing digital geometry in vdgl (e.g., by its > replacement of cast_to_digital_curve()). We (Brown) are using vsol_digital_curve_2d for dense points (often converting vdgl_digital_curve to vsol_digital_curve_2d). We also hope to add a similar vsol_digital_curve_3d based on the same concepts. There is no concept of a 3D edgel, and we want the 2D and 3D implementations to be similar. Ultimately the vsol_polyline_2d might not be need. It has a subset of the functionality of vsol_digital_curve_2d. However, I assume it should be left for now since it is commonly used for sparse points producing a set of connected line segments. We may ultimately switch to higher order interpolation and we don't want this to cause problems for those who use a polyline and expect to get linear segments. -Matt Leotta |
From: Peter V. <Pet...@es...> - 2004-09-27 18:36:57
|
> The guide points in vdgl are actually more that pairs of doubles. They > are edgels, which are pairs of doubles with two more doubles for > gradient and orientation (4 doubles at each point). This is really > targeted towards use in edge detection. Agreed. > The intent of the vsol_digital_curve_2d was to remove the additional > edge detection information and allow more direct access to underlying > points while still allowing for the concept of a continuous structure > via interpolation. Wouldn't it be better, then, to use a vcl_vector<vgl_point_2d<double> >, i.e., a light-weight point containing just 2 doubles? Now the points are really heavy: x, y, bounding_box, tag, id, time_stamp, ref_count. Smartness is not an issue here since the points are just used internally. > Currently interpolation is linear, but we would like to find a way to > abstractly allow a choice of interpolation function without all the > mess of the extra layers in vdgl. Then I see a simple option: use vsol_polyline_2d (extended with the methods interp(), closest_index() and split()) when you need linear interpolation, and use a new class (vsol_spline_2d or so) when you want higher-order interpolation. When designing an abstract interpolation interface, you will end up with something similar to the vdgl_digital_curve layers. I can understand the need for something "inbetween" vsol_polyline_2d and vdgl_digital_curve, without the bias towards edge detection. But I would propose to place such a class in vdgl, which is really the location for "digital geometry". -- Peter. |