[vtk-developers] Proposing vtkObjectMacro

[Robert Maynard]

+1 I fully support any reduction in the amount of boilerplate code in each
VTK class header, and this also decreases the number
of mistakes that developers have while writing new classes.

On Thu, Sep 13, 2012 at 10:58 AM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> On Thu, Sep 13, 2012 at 10:16 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > On Thu, Sep 13, 2012 at 9:53 AM, Kyle Lutz <kyle.lutz at kitware.com>
> wrote:
> >>
> >> On Thu, Sep 13, 2012 at 6:48 AM, Aashish Chaudhary
> >> <aashish.chaudhary at kitware.com> wrote:
> >> > +1, can we add virtual keyword in front of the ~className()?
> >> >
> >> > Or are you going to rely on the fact that the parent class has defined
> >> > its
> >> > destructor virtual (like vtkObject?)
> >>
> >> The macro is only intended for classes deriving from vtkObject (really
> >> vtkObjectBase) so declaring the destructor as virtual would be
> >> redundant.
> >
> > Yes, but in general IMO, it is not a good practice to leave virtual
> keyword
> > out just because base class has declared virtual destructor.  Also
> implicit
> > something is not good unless properly documented. Since we are talking
> about
> > a macro, I don't think its too bad to have virtual keyword in front of
> the
> > desctructor.
> >
> I am in favor of adding the macro, and disagree with Utkarsh in that
> we already have the type macro etc and it will remove the need for a
> lot of boiler plate code in each class declaration. I really agree
> with Kyle - it is only intended for (and would only work) with
> vtkObjectBase derived classes and so the virtual keyword is redundant.
>
> This has bothered me for a long time, and I never found time to write
> the macro. I think it would be a great addition, the vtkObjectMacro
> was inspired by the Q_OBJECT macro, vtkClassMacro and
> vtkAbstractClassMacro sound good to me. We wanted to get consensus on
> the common case before extending it to the abstract case.
>
> I think removing PrintSelf would be reasonable, as David states not
> all classes will have ivars and the developer of the class must
> implement the function body as Utkarsh pointed out.
>
> My $0.03.
>
> Marcus
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>


-- 
Robert Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120913/0aedb36d/attachment.html>