[vtk-developers] Shared ownership of an array of pointers

[Philippe Pébay]

Hello David

Yes, I think this is the best option. I am thinking that I could create
this as a new concrete subclass of vtkAbstractArray available to all, and
not only as a helper class internal to my hyper tree implementation. What
do you think? Would this be useful?

Thanks
Philippe

On Tue, Nov 20, 2012 at 6:25 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Phillippe,
>
> Actually I was wrong about vtkVariant not having any size overhead.  It
> needs
> to store the type along with the value.  So vtkVariantArray is no good for
> this.
>
> A helper class might be the best option.  You could make a vtkObjectArray
> class which would be just like vtkVoidArray except that it would objects.
>
>  - David
>
>
> On Tue, Nov 20, 2012 at 9:54 AM, Philippe Pébay
> <philippe.pebay at kitware.com> wrote:
> > Hello David
> >
> > Thanks for the summary about the absence of performance hit when using
> SPs
> > as opposed to RPs. I will remember it and use them more often as a
> result.
> >
> > Regarding the variant array, yes, the conversion to vtkObject is a
> concern.
> > I think that the most efficient option would be to create a small helper
> > class that would internally store a raw array of pointers. That helper
> would
> > derive from vtkObjectBase. That should avoid any perfomance hit.
> >
> > Philippe
> >
> >
> > On Tue, Nov 20, 2012 at 5:49 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> Hi Phillippe,
> >>
> >> A vtkVariant is 64 bits, it should be no larger than a pointer.  There
> >> is a function call overhead in ToVTKObject(), which might be a concern
> to
> >> you.
> >>
> >> The vtkSmartPointer is exactly the same size as a pointer, so there is
> no
> >> size
> >> overhead.  It has no computational overhead, either, except for the
> >> "operator=",
> >> the copy constructor, and the destructor (I wouldn't even count the
> >> overhead in
> >> the destructor, because you have to call ->Delete() eventually anyway).
> >> So do
> >> not avoid smart pointers because you are worried about efficiency.  The
> >> VTK
> >> smart pointers are very efficient because vtkObjectBase already has a
> >> built-in
> >> reference count.
> >>
> >>  - David
> >>
> >>
> >> On Tue, Nov 20, 2012 at 9:35 AM, Philippe Pébay
> >> <philippe.pebay at kitware.com> wrote:
> >> > Hello David
> >> >
> >> > Thanks for the suggestion: I am concerned by the overhead that comes
> >> > with
> >> > variants. Wouldn't it be more lightweight to use a vtkVoidArray
> instead?
> >> > The
> >> > array can potentially contain O(10⁶) pointers. By the way this is for
> >> > the
> >> > same reason that I have, so far, refrained from using vtkSmartPointers
> >> > as
> >> > opposed to raw pointers, by fear of the overhead involved. Is this
> extra
> >> > caution excessive?
> >> >
> >> > Thanks
> >> > Philippe
> >> >
> >> > On Tue, Nov 20, 2012 at 5:31 PM, David Gobbi <david.gobbi at gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi Philippe,
> >> >>
> >> >> If the pointers are pointers to VTK objects, then you can use
> >> >> vtkVariantArray.
> >> >>
> >> >>  - David
> >> >>
> >> >>
> >> >> On Tue, Nov 20, 2012 at 9:29 AM, Philippe Pébay
> >> >> <philippe.pebay at kitware.com> wrote:
> >> >> > Just an idea: couldn't a vtkVoidArray be used (or abused) as
> >> >> > container
> >> >> > of
> >> >> > raw pointers, that would be appropriately downcasted internally to
> >> >> > the
> >> >> > concrete type to which they are supposed to point? For instance,
> >> >> > instead
> >> >> > of
> >> >> > having a
> >> >> >  vtkMyInternalObject** obj
> >> >> > instance variable, couldn't I use a
> >> >> >  vtkVoidArray* obj
> >> >> > instead, where each entry in obj would be the raw pointer to a
> >> >> > vtkSmartPointer<vtkMyInternalObject>?
> >> >> >
> >> >> > Thanks
> >> >> > Philippe
> >> >> >
> >> >> >
> >> >> > On Tue, Nov 20, 2012 at 5:14 PM, Philippe Pébay
> >> >> > <philippe.pebay at kitware.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hello Kyle
> >> >> >>
> >> >> >> Yes, I would want to avoid a dependency on Boost. But this is
> >> >> >> basically
> >> >> >> what I am tried to reproduce (the Boost shared array of pointers).
> >> >> >>
> >> >> >> Thanks
> >> >> >> P
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Nov 20, 2012 at 5:13 PM, Kyle Lutz <kyle.lutz at kitware.com
> >
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Would using boost suffice? Or do you want a solution using just
> >> >> >>> VTK?
> >> >> >>>
> >> >> >>> -kyle
> >> >> >>>
> >> >> >>> On Tue, Nov 20, 2012 at 7:58 AM, Philippe Pébay
> >> >> >>> <philippe.pebay at kitware.com> wrote:
> >> >> >>> > Hello all,
> >> >> >>> >
> >> >> >>> > I need to keep track of shared ownership of an array of
> pointers.
> >> >> >>> > Can
> >> >> >>> > someone point me towards an example of code that already does
> >> >> >>> > this?
> >> >> >>> > This
> >> >> >>> > should amount to a small helper class that contains the array
> of
> >> >> >>> > pointers
> >> >> >>> > along with a reference count.
> >> >> >>> >
> >> >> >>> > Thank you!
> >> >> >>> > Philippe
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > --
> >> >> >>> > Philippe Pébay, PhD
> >> >> >>> > Director of Visualization and High Performance Computing /
> >> >> >>> > Directeur de la Visualisation et du Calcul Haute Performance
> >> >> >>> > Kitware SAS
> >> >> >>> > 26 rue Louis Guérin, 69100 Villeurbanne, France
> >> >> >>> > +33 (0) 6.83.61.55.70 / 4.37.45.04.15
> >> >> >>> > http://www.kitware.fr
> >
> >
> >
> >
> > --
> > Philippe Pébay, PhD
> > Director of Visualization and High Performance Computing /
> > Directeur de la Visualisation et du Calcul Haute Performance
> > Kitware SAS
> > 26 rue Louis Guérin, 69100 Villeurbanne, France
> > +33 (0) 6.83.61.55.70 / 4.37.45.04.15
> > http://www.kitware.fr
>



-- 
Philippe Pébay, PhD
Director of Visualization and High Performance Computing /
Directeur de la Visualisation et du Calcul Haute Performance
Kitware SAS
26 rue Louis Guérin, 69100 Villeurbanne, France
+33 (0) 6.83.61.55.70 / 4.37.45.04.15
http://www.kitware.fr <http://www.kitware.fr/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20121120/321e2ea9/attachment.html>