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.<div>
<br></div><div>Marcus<div><br><div class="gmail_quote">On Wed, Oct 6, 2010 at 9:25 AM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I was wondering about that dynamic_cast but I thought there<br>
was a reason for it... but I can change it to a static_cast<br>
for my commit.<br>
<br>
So I'll stage and commit as soon as I can afford a full VTK<br>
rebuild.<br>
<br>
David<br>
<br>
On Wed, Oct 6, 2010 at 7:06 AM, Utkarsh Ayachit<br>
<div class="im"><<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> I like your changes. In absence of your changes, if a developer does<br>
> indeed want to achieve same effect he'll be doing something similar<br>
> and will indeed have the onus of worrying about dangling ptrs. So I<br>
> don't think this makes it any more confusing. We should probably add<br>
> documentation to that effect and that pretty much should do it.<br>
><br>
> About the dynamic_cast, yea static_cast should be fine too and totally<br>
> safe in this case. If the developer was stupid enough to pass in a ptr<br>
> as a wrong type when making the AddObserver call, he deserves the side<br>
> effects :).<br>
><br>
> I'd vote for committing your changes. (You should use the stage, add<br>
> your commit to the "member_function_observers" branch and then merge<br>
> it in).<br>
><br>
> Utkarsh<br>
><br>
> On Wed, Oct 6, 2010 at 8:24 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>> On Wed, Oct 6, 2010 at 6:01 AM, David Doria <<a href="mailto:daviddoria@gmail.com">daviddoria@gmail.com</a>> wrote:<br>
>>><br>
>>> David G,<br>
>>><br>
>>> Are you suggesting this in place of what Utkarsh pushed? Utkarsh, can<br>
>>> you take a look and let David G know if he should push it? I think it<br>
>>> is a good idea to allow event handling from as many places as possible<br>
>>> (i.e. I support NOT requiring the class to derive from vtkObjectBase).<br>
>><br>
>> I'm just putting it out for discussion. It does come with some danger,<br>
>> for example you should not use it instead of vtkEventQtSlotConnect,<br>
>> because Qt's signal/slot mechanism is safe, and this is not. It's only<br>
>> safe when the listener is a vtkObjectBase class.<br>
>><br>
>> David<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>
_______________________________________________<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></div></div>