[vtk-developers] [Paraview-developers] Moving vtkMemberFunctionCommand to VTK

[David Gobbi]

I found a way around the dynamic_cast by templating the "Pointer"
helper class.  It even allowed me to remove 10 lines of code.

  David


On Wed, Oct 6, 2010 at 11:09 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Works for me.
>
> Utkarsh
>
> On Wed, Oct 6, 2010 at 11:59 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> A reinterpret_cast gives an undefined result when casting an object
>> with multiple inheritance.  So I think that it is better to live with
>> the overhead of a dynamic cast, just in case someone tries using this
>> with a class like vtkQtView (it multi-inherits from QObject).
>>
>>  David
>>
>>
>> On Wed, Oct 6, 2010 at 9:51 AM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> You actually need a reinterpret_cast<>.
>>>
>>> Utkarsh
>>>
>>> On Wed, Oct 6, 2010 at 11:45 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> The dynamic_cast is necessary, after all.  The problem is here:
>>>>
>>>>  T* handler = static_cast<T*>(this->Handler.GetPointer());
>>>>
>>>> The GetPointer() returns a vtkObjectBase, so this line of
>>>> code refuses to compile for "other" objects.
>>>>
>>>>  David
>>>>
>>>> On Wed, Oct 6, 2010 at 7:48 AM, Marcus D. Hanwell
>>>> <marcus.hanwell at kitware.com> wrote:
>>>>> I was about to ask if a static_cast would work in this case, and it seems
>>>>> preferable (and equivalent to) a C-style cast. I was just looking at the new
>>>>> API, and it looks great to me. I think this is a great addition to our C++
>>>>> API, and am very much in favor of making it slicker where we can.
>>>>> Marcus
>>>>> On Wed, Oct 6, 2010 at 9:25 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>
>>>>>> I was wondering about that dynamic_cast but I thought there
>>>>>> was a reason for it... but I can change it to a static_cast
>>>>>> for my commit.
>>>>>>
>>>>>> So I'll stage and commit as soon as I can afford a full VTK
>>>>>> rebuild.
>>>>>>
>>>>>>  David
>>>>>>
>>>>>> On Wed, Oct 6, 2010 at 7:06 AM, Utkarsh Ayachit
>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>> > I like your changes. In absence of your changes, if a developer does
>>>>>> > indeed want to achieve same effect he'll be doing something similar
>>>>>> > and will indeed have the onus of worrying about dangling ptrs. So I
>>>>>> > don't think this makes it any more confusing. We should probably add
>>>>>> > documentation to that effect and that pretty much should do it.
>>>>>> >
>>>>>> > About the dynamic_cast, yea static_cast should be fine too and totally
>>>>>> > safe in this case. If the developer was stupid enough to pass in a ptr
>>>>>> > as a wrong type when making the AddObserver call, he deserves the side
>>>>>> > effects :).
>>>>>> >
>>>>>> > I'd vote for committing your changes. (You should use the stage, add
>>>>>> > your commit to the "member_function_observers" branch and then merge
>>>>>> > it in).
>>>>>> >
>>>>>> > Utkarsh
>>>>>> >
>>>>>> > On Wed, Oct 6, 2010 at 8:24 AM, David Gobbi <david.gobbi at gmail.com>
>>>>>> > wrote:
>>>>>> >> On Wed, Oct 6, 2010 at 6:01 AM, David Doria <daviddoria at gmail.com>
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>> David G,
>>>>>> >>>
>>>>>> >>> Are you suggesting this in place of what Utkarsh pushed? Utkarsh, can
>>>>>> >>> you take a look and let David G know if he should push it? I think it
>>>>>> >>> is a good idea to allow event handling from as many places as possible
>>>>>> >>> (i.e. I support NOT requiring the class to derive from vtkObjectBase).
>>>>>> >>
>>>>>> >> I'm just putting it out for discussion.  It does come with some danger,
>>>>>> >> for example you should not use it instead of vtkEventQtSlotConnect,
>>>>>> >> because Qt's signal/slot mechanism is safe, and this is not.  It's only
>>>>>> >> safe when the listener is a vtkObjectBase class.
>>>>>> >>
>>>>>> >>  David
>>>>>> >>
>>>>>> > _______________________________________________
>>>>>> > 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>