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

[David Gobbi]

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