[vtk-developers] Proposing vtkObjectMacro

[Bill Lorensen]

+1 from me. I prefer vtkClassMacro.

On Thu, Sep 13, 2012 at 11:01 AM, Robert Maynard <robert.maynard at kitware.com
> wrote:

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


-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120913/8644f4df/attachment.html>