[Insight-developers] pure virtual methods vs exceptions throwing

[Stephen R. Aylward]

Luis,

I really like this design.  Very nice!

Only other option would be to keep smart pointers from doing
construction...

Thanks,
Stephen

Luis Ibanez wrote:
> 
> Bill,
> 
> I have been hesitating about how to manage these cases
> and would appreciate any comments on how to do it better.
> 
> It is happening now in Transforms, CostFuctions,
> Spatial Functions and a couple of other classes.
> 
> The problem is:
> 
> In order to remove template parameters we went back to
> classical C++ where we have hierarchies of classes (e.g.
> a hierarchy of transforms, a hierarchy of optimizers, a hierarchy
> of cost functions). Each hierarchy has a Base class that works
> as a generic representative of all the hierarchy members.
> 
> Classes that require a Transform only keep a SmartPointer to
> the base class of the Transform hierarchy...and so on.
> At run time, the user will plug in a real functional member of the
> hierarchy into the pointer to the generic one and all the calls will
> be done via virtual functions.
> 
> The Base classes of the  hierarchy are quite dummy. They are
> devoid of  all functionality in themselves and are never expected
> to be instantiated.   So in principle most of their methods could
> be declared pure virtual:
> 
>     virtual     method()   = 0;
> 
> but...
> 
> For some reason, classes that hold smart pointer to these
> base classes try to instantiate them as construction time.
> That results in a message like:
> 
>          class YYY cannot be instantiated because
>          the method ZZZ is abstract.
> 
> This is triggered by the      itkNewMacro() .... as current
> messages from the SGIs show in the dashboard.
> 
> In order to avoid this, I removed pure virtual from methods
> in the base classes and wrote dummy implementations for them.
> This has the risk that classes deriving from them may forget
> to overload these dummy method and they may end up being
> called at run-time producing  absurd results.
> 
> So....I throw exceptions on them !
> 
> These methos should never be called.
> If they are called that means that a derived class
> is not overloading a method that must be overloaded....
> 
> If the run time test were crashing because of exceptions
> that means that some derived class was not being correctly
> implemented.
> 
> ======================================
> To summarize:
> 
> It looks like we have two options:
> 
> 1) Go back to pure virtual methods (and find a workaround
> for the itkNewMacro() instantiation problem. That will give
> compile-time error is some derived class is not overloading
> the right methods.
> 
> 2) Keep methods just virtual and do something to signal
> that this method should not be called... that can be:
> - Keep throwing exeptions.
> - Print some kind of message .. Warning.. Error....
> =======================================
> 
> Any  advice on this will be welcome !
> 
> ===================================
> Lorensen, William E (CRD) wrote:
> 
> >Luis,
> >        Subclasses of CostFunction were throwing an exception if the method GetNumberOfParameters
> >was not defined. This was causing some optimizer tests to crash. These required methods should really
> >be pure virtual so that the compiler detects the missing method. I changed CostFunction to do this so
> >you may see a few more compile errors show up.
> >
> >Bill
> >_______________________________________________
> >Insight-developers mailing list
> >Insight-developers@public.kitware.com
> >http://public.kitware.com/mailman/listinfo/insight-developers
> >
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers

-- 
===============================================
Dr. Stephen R. Aylward
Assistant Professor of Radiology
Adjunct Assistant Professor of Computer Science
http://caddlab.rad.unc.edu
aylward@unc.edu
(919) 966-9695