The VXL Project

>  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.

> >  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

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.

> "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.

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-maintainers@...
>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

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.

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 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.

> 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

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.

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

> 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();
         }

> 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.