[vtk-developers] AddObserver taking C++11 lambda?

[David Gobbi]

Hi Chris,

If I'm reading the Qt docs correctly, then the "context" object that
connect() uses is simply any Qt object.  If we add an AddObserver() that
takes lambdas or function pointers, then we could similarly take a
"context" object that would be any vtkObjectBase-derived object.  But as
far as I understand, this wouldn't be generalizable to non-vtk objects.

 - David


On Thu, Mar 23, 2017 at 9:13 AM, Chris Harris <chris.harris at kitware.com>
wrote:

> Qt provides help for this situation ( in the signal  world ) by allowing a
> "context object" to be provided on the connect, which causes the signal to
> be disconnected when the object is destroyed. Could something similar work
> here?
>
> Chris
>
> On Thu, Mar 23, 2017 at 10:55 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Hi Robert,
>>
>> Our AddObserver() methods only use weak pointers when the observer is
>> derived from vtkObjectBase, which means that currently if the observer is
>> not a VTK object, then we have a situation where we might call a dangling
>> pointer.  I'm not aware of any uniform way around get around this issue
>> except for using std::weak_ptr, which in turn demands that any non-vtk
>> observer objects are wrapped with a std::shared_ptr.
>>
>> When people start using lambdas with AddObserver, about the only thing we
>> can do for safety is provide rules such as the ones that you describe to
>> ensure that the lambda doesn't capture pointers that can be left dangling.
>>
>> Thanks, by the way, for working on the c++11 guidelines.
>>
>>  - David
>>
>> On Thu, Mar 23, 2017 at 8:31 AM, Robert Maynard <
>> robert.maynard at kitware.com> wrote:
>>
>>> While allowing lambda's to be held by std::function is really nice, it
>>> becomes very easy to mistakenly captures items whose lifetime is
>>> shorter than the Observer you are binding too.
>>>
>>> I am currently writing up the first draft of c++11 guidelines for VTK
>>> and for lambda functions and these are the guidelines I currently
>>> have:
>>>
>>> Usage of lambda expressions are allowed with the following guidelines.
>>>
>>> - Use default capture by value ([=]) only as a means of binding a few
>>> variables for a short lambda, where the set of captured variables is
>>> obvious at a glance. Prefer not to write long or complex lambdas with
>>> default capture by value.
>>> - Except for the above, all capture arguments must be explicitly
>>> captured. Using the default capture by reference ([&]) is not allowed.
>>> This is to done so that it is easier to evaluate lifespan and
>>> reference ownership.
>>> - Keep unnamed lambdas short. If a lambda body is more than maybe five
>>> lines long, prefer using a named function instead of a lambda.
>>> - Specify the return type of the lambda explicitly if that will make
>>> it more obvious to readers.
>>>
>>> On-top of these guidelines I have also stated that lambda functions
>>> should be kept to implementation files in VTK, which is fine as we go
>>> with an approach like David proposed.
>>>
>>> On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik
>>> <elvis.stansvik at orexplore.com> wrote:
>>> > Den 22 mars 2017 6:48 em skrev "David Gobbi" <david.gobbi at gmail.com>:
>>> >>
>>> >> It doesn't look hard.  New AddObserver methods would be needed that
>>> take
>>> >> std::function<> as a parameter, and they'd have to store the
>>> "function"
>>> >> object and call it.  Overall, it would probably be simpler than the
>>> code
>>> >> that currently exists in vtkObject.h for adding observers.
>>> >
>>> > Good to hear, I might have a go at it then.
>>> >
>>> > Elvis
>>> >
>>> >>
>>> >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik
>>> >> <elvis.stansvik at orexplore.com> wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> With C++11 now required, would there be interest in an AddObserver
>>> >>> version that takes a C++11 lambda? I've found myself wishing there
>>> was
>>> >>> one a couple of times.
>>> >>>
>>> >>> Anyone know off the top of their head how easy/hard that would be to
>>> add?
>>> >>>
>>> >>> Cheers,
>>> >>> Elvis
>>> >>> _______________________________________________
>>> >>> Powered by www.kitware.com
>>> >>>
>>> >>> Visit other Kitware open-source projects at
>>> >>> http://www.kitware.com/opensource/opensource.html
>>> >>>
>>> >>> Search the list archives at: http://markmail.org/search/?q=
>>> vtk-developers
>>> >>>
>>> >>> Follow this link to subscribe/unsubscribe:
>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>> >>>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Powered by www.kitware.com
>>> >
>>> > Visit other Kitware open-source projects at
>>> > http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Search the list archives at: http://markmail.org/search/?q=
>>> vtk-developers
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>> >
>>> >
>>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170323/343159e3/attachment.html>