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

[Utkarsh Ayachit]

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