[prev in list] [next in list] [prev in thread] [next in thread]
List: vtk-developers
Subject: Re: [vtk-developers] Proposing vtkObjectMacro
From: Bill Lorensen <bill.lorensen () gmail ! com>
Date: 2012-09-13 19:22:35
Message-ID: CADZJ4hPmnVGQ_cO7gMd11HCH+F_0Vo-6VuHYiv0B0uWp-vFnPg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Since it is a real pain when vtkSetGet.h is changed (at least for old guys
with slow machines), why not add vtkAbstractClassMacro now?
On Thu, Sep 13, 2012 at 3:12 PM, Kyle Lutz <kyle.lutz@kitware.com> wrote:
> Thanks all for the input.
>
> For now I'd like to keep the discussion targeted at vtkClassMacro(). A
> macro for abstract classes (which VTK has far fewer of) could be added
> later if vtkClassMacro() proves useful. Furthermore, I don't really
> think using a vtkDisableCopy() type macro is the proper way to
> prohibit copying of VTK classes. vtkObjectBase should just declare its
> copy constructor and assignment operator as private a la
> boost::noncopyable (but this is a larger change than I feel
> comfortable making).
>
> I've re-pushed the topic with the constructor and destructor
> declarations removed. Now the documentation looks like this:
>
> // Description:
> // Declares a vtkObject subclass.
> //
> // Notably, performs the following actions:
> // - invokes the vtkTypeMacro()
> // - disables its copy constructor and assignment operator
> // - declares its static *New() method
> #define vtkClassMacro(className, parentClassName)
>
> -kyle
>
> On Thu, Sep 13, 2012 at 11:49 AM, Marcus D. Hanwell
> <marcus.hanwell@kitware.com> wrote:
> > That much wasn't clear to me in the other suggestions. I would like to
> > see a vtkClassMacro and vtkAbstractClassMacro, and thought that was
> > what was being converged on.
> >
> > On Thu, Sep 13, 2012 at 2:44 PM, Utkarsh Ayachit
> > <utkarsh.ayachit@kitware.com> wrote:
> >> I am suggesting the vtkDisableCopy() macro as an alternative to the
> >> vtkClassMacro() since after stripping out the controversial parts for
> >> vtkClassMacro() all that remains is disable copy, vtkTypeMacro() and
> >> New() and frankly, New() is also not always needed since it doens't
> >> work for abstract classes.
> >>
> >>
> >> On Thu, Sep 13, 2012 at 2:40 PM, Marcus D. Hanwell
> >> <marcus.hanwell@kitware.com> wrote:
> >>> Why provide a disable copy macro when it is a requirement of vtkObject
> >>> derived classes? It should just be part of the vtkClassMacro, with
> >>> QObject derived classes they can have copy constructors, and so
> >>> provided an option makes more sense there.
> >>>
> >>> On Thu, Sep 13, 2012 at 2:29 PM, Aashish Chaudhary
> >>> <aashish.chaudhary@kitware.com> wrote:
> >>>> +1 to remove construct and destructor. Also I think like Qt we should
> >>>> provide disable copy macro and use it in vtkClassMacro.
> >>>>
> >>>> Thanks,
> >>>>
> >>>>
> >>>> On Thu, Sep 13, 2012 at 12:39 PM, Cory Quammen <cquammen@cs.unc.edu>
> wrote:
> >>>>>
> >>>>> +1 if you remove the constructors/destructor declarations.
> >>>>>
> >>>>> Cory
> >>>>>
> >>>>> On Thu, Sep 13, 2012 at 11:33 AM, Patchett, John M <
> patchett@lanl.gov>
> >>>>> wrote:
> >>>>> > Though I don't usually involve myself in VTK development, I think
> >>>>> > that obfuscated understandability is part of the reason that I've
> seen
> >>>>> > a large number of otherwise bright developers (students) become
> >>>>> > integration impotent when asked to put their ideas/code in
> >>>>> > VTK/ParaView...
> >>>>> > If a goal is to have contributors, this is a bad idea.
> >>>>> >
> >>>>> >
> >>>>> > --John.
> >>>>> >
> >>>>> >
> >>>>> > On 9/13/12 9:22 AM, "Marcus D. Hanwell" <
> marcus.hanwell@kitware.com>
> >>>>> > wrote:
> >>>>> >
> >>>>> >>On Thu, Sep 13, 2012 at 11:07 AM, Utkarsh Ayachit
> >>>>> >><utkarsh.ayachit@kitware.com> wrote:
> >>>>> >>>> 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.
> >>>>> >>>
> >>>>> >>> Note that vtkTypeMacro() doesn't force you to add anything in
> the cxx
> >>>>> >>> file. You can pretty much not know what that macro does and
> you're
> >>>>> >>> okay. Not so with this macro. Also hiding constructor/destructor
> is
> >>>>> >>> really weird to me. Why would you? I don't think I am thrilled by
> >>>>> >>> having to implement function definitions without seeing their
> >>>>> >>> declarations in the header. None of the existing macros do that,
> not
> >>>>> >>> even in Qt, as far as I know. Readability of code is far more
> >>>>> >>> important that saving typing a few more lines, IMHO.
> >>>>> >>>
> >>>>> >>I can see your point with the contructor/desctructor. Even with
> them
> >>>>> >>removed I still think this macro would be very useful.
> >>>>> >>
> >>>>> >>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
> >>>>> >>
> >>>>> >
> >>>>> > _______________________________________________
> >>>>> > 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
> >>>>> >
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Cory Quammen
> >>>>> Research Associate
> >>>>> Department of Computer Science
> >>>>> The University of North Carolina at Chapel Hill
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> | Aashish Chaudhary
> >>>> | R&D Engineer
> >>>> | Kitware Inc.
> >>>> | www.kitware.com
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>>>
> >>> _______________________________________________
> >>> 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
> >>>
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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
[Attachment #5 (text/html)]
Since it is a real pain when vtkSetGet.h is changed (at least for old guys with slow \
machines), why not add vtkAbstractClassMacro now?<br><br><div class="gmail_quote">On \
Thu, Sep 13, 2012 at 3:12 PM, Kyle Lutz <span dir="ltr"><<a \
href="mailto:kyle.lutz@kitware.com" \
target="_blank">kyle.lutz@kitware.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Thanks all for the input.<br> <br>
For now I'd like to keep the discussion targeted at vtkClassMacro(). A<br>
macro for abstract classes (which VTK has far fewer of) could be added<br>
later if vtkClassMacro() proves useful. Furthermore, I don't really<br>
think using a vtkDisableCopy() type macro is the proper way to<br>
prohibit copying of VTK classes. vtkObjectBase should just declare its<br>
copy constructor and assignment operator as private a la<br>
boost::noncopyable (but this is a larger change than I feel<br>
comfortable making).<br>
<br>
I've re-pushed the topic with the constructor and destructor<br>
declarations removed. Now the documentation looks like this:<br>
<div class="im"><br>
// Description:<br>
// Declares a vtkObject subclass.<br>
//<br>
// Notably, performs the following actions:<br>
// - invokes the vtkTypeMacro()<br>
</div><div class="im">// - disables its copy constructor and assignment \
operator<br> // - declares its static *New() method<br>
</div>#define vtkClassMacro(className, parentClassName)<br>
<br>
-kyle<br>
<br>
On Thu, Sep 13, 2012 at 11:49 AM, Marcus D. Hanwell<br>
<div class="HOEnZb"><div class="h5"><<a \
href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> \
wrote:<br> > That much wasn't clear to me in the other suggestions. I would \
like to<br> > see a vtkClassMacro and vtkAbstractClassMacro, and thought that \
was<br> > what was being converged on.<br>
><br>
> On Thu, Sep 13, 2012 at 2:44 PM, Utkarsh Ayachit<br>
> <<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> \
wrote:<br> >> I am suggesting the vtkDisableCopy() macro as an alternative to \
the<br> >> vtkClassMacro() since after stripping out the controversial parts \
for<br> >> vtkClassMacro() all that remains is disable copy, vtkTypeMacro() \
and<br> >> New() and frankly, New() is also not always needed since it \
doens't<br> >> work for abstract classes.<br>
>><br>
>><br>
>> On Thu, Sep 13, 2012 at 2:40 PM, Marcus D. Hanwell<br>
>> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> \
wrote:<br> >>> Why provide a disable copy macro when it is a requirement of \
vtkObject<br> >>> derived classes? It should just be part of the \
vtkClassMacro, with<br> >>> QObject derived classes they can have copy \
constructors, and so<br> >>> provided an option makes more sense there.<br>
>>><br>
>>> On Thu, Sep 13, 2012 at 2:29 PM, Aashish Chaudhary<br>
>>> <<a href="mailto:aashish.chaudhary@kitware.com">aashish.chaudhary@kitware.com</a>> \
wrote:<br> >>>> +1 to remove construct and destructor. Also I think like \
Qt we should<br> >>>> provide disable copy macro and use it in \
vtkClassMacro.<br> >>>><br>
>>>> Thanks,<br>
>>>><br>
>>>><br>
>>>> On Thu, Sep 13, 2012 at 12:39 PM, Cory Quammen <<a \
href="mailto:cquammen@cs.unc.edu">cquammen@cs.unc.edu</a>> wrote:<br> \
>>>>><br> >>>>> +1 if you remove the \
constructors/destructor declarations.<br> >>>>><br>
>>>>> Cory<br>
>>>>><br>
>>>>> On Thu, Sep 13, 2012 at 11:33 AM, Patchett, John M <<a \
href="mailto:patchett@lanl.gov">patchett@lanl.gov</a>><br> >>>>> \
wrote:<br> >>>>> > Though I don't usually involve myself in VTK \
development, I think<br> >>>>> > that obfuscated understandability \
is part of the reason that I've seen<br> >>>>> > a large number \
of otherwise bright developers (students) become<br> >>>>> > \
integration impotent when asked to put their ideas/code in<br> >>>>> \
> VTK/ParaView...<br> >>>>> > If a goal is to have contributors, \
this is a bad idea.<br> >>>>> ><br>
>>>>> ><br>
>>>>> > --John.<br>
>>>>> ><br>
>>>>> ><br>
>>>>> > On 9/13/12 9:22 AM, "Marcus D. Hanwell" <<a \
href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>><br> \
>>>>> > wrote:<br> >>>>> ><br>
>>>>> >>On Thu, Sep 13, 2012 at 11:07 AM, Utkarsh Ayachit<br>
>>>>> >><<a \
href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> \
wrote:<br> >>>>> >>>> I am in favor of adding the macro, \
and disagree with Utkarsh in that<br> >>>>> >>>> we \
already have the type macro etc and it will remove the need for a<br> \
>>>>> >>>> lot of boiler plate code in each class \
declaration.<br> >>>>> >>><br>
>>>>> >>> Note that vtkTypeMacro() doesn't force you to \
add anything in the cxx<br> >>>>> >>> file. You can pretty \
much not know what that macro does and you're<br> >>>>> \
>>> okay. Not so with this macro. Also hiding constructor/destructor is<br> \
>>>>> >>> really weird to me. Why would you? I don't \
think I am thrilled by<br> >>>>> >>> having to implement \
function definitions without seeing their<br> >>>>> >>> \
declarations in the header. None of the existing macros do that, not<br> \
>>>>> >>> even in Qt, as far as I know. Readability of code \
is far more<br> >>>>> >>> important that saving typing a few \
more lines, IMHO.<br> >>>>> >>><br>
>>>>> >>I can see your point with the contructor/desctructor. \
Even with them<br> >>>>> >>removed I still think this macro \
would be very useful.<br> >>>>> >><br>
>>>>> >>Marcus<br>
>>>>> >>_______________________________________________<br>
>>>>> >>Powered by <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> >>>>> >><br>
>>>>> >>Visit other Kitware open-source projects at<br>
>>>>> >><a \
href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> \
>>>>> >><br> >>>>> >>Follow this link to \
subscribe/unsubscribe:<br> >>>>> >><a \
href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> \
>>>>> >><br> >>>>> ><br>
>>>>> > _______________________________________________<br>
>>>>> > Powered by <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> >>>>> ><br>
>>>>> > Visit other Kitware open-source projects at<br>
>>>>> > <a href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> \
>>>>> ><br> >>>>> > Follow this link to \
subscribe/unsubscribe:<br> >>>>> > <a \
href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> \
>>>>> ><br> >>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Cory Quammen<br>
>>>>> Research Associate<br>
>>>>> Department of Computer Science<br>
>>>>> The University of North Carolina at Chapel Hill<br>
>>>>> _______________________________________________<br>
>>>>> Powered by <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> >>>>><br>
>>>>> Visit other Kitware open-source projects at<br>
>>>>> <a href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> \
>>>>><br> >>>>> Follow this link to \
subscribe/unsubscribe:<br> >>>>> <a \
href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> \
>>>>><br> >>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> | Aashish Chaudhary<br>
>>>> | R&D Engineer<br>
>>>> | Kitware Inc.<br>
>>>> | <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> >>>><br>
>>>> _______________________________________________<br>
>>>> Powered by <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> >>>><br>
>>>> Visit other Kitware open-source projects at<br>
>>>> <a href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> \
>>>><br> >>>> Follow this link to subscribe/unsubscribe:<br>
>>>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> \
>>>><br> >>>><br>
>>> _______________________________________________<br>
>>> Powered by <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> >>><br>
>>> Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> \
>>><br> >>> Follow this link to subscribe/unsubscribe:<br>
>>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> \
>>><br> > _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" \
target="_blank">www.kitware.com</a><br> ><br>
> Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> ><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> ><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> <br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" \
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> <br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Unpaid intern in \
BillsBasement at noware dot com<br><br>
_______________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic