RFC: STL algos and C++11 for-range syntax with vtkDataArrays

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Allie Vacanti
Hi folks,

I've written a set of STL-compatible utilities that allow vtkDataArrays to be efficiently used with STL algorithms as well as with C++11 for-range syntax. This consists of TupleRanges, which iterate through an array tuple-by-tuple and component-by-component, and ValueRanges, which iterate element-by-element using AOS-ordering.

I've linked a blog post describing them in more detail, and a merge request available to play with / review / nitpick for anyone interested in doing so =)

https://blog.kitware.com/c11-for-range-support-in-vtk/
https://gitlab.kitware.com/vtk/vtk/merge_requests/4826

Allie

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Elvis Stansvik
Den tors 8 nov. 2018 kl 23:21 skrev Allie Vacanti <[hidden email]>:

>
> Hi folks,
>
> I've written a set of STL-compatible utilities that allow vtkDataArrays to be efficiently used with STL algorithms as well as with C++11 for-range syntax. This consists of TupleRanges, which iterate through an array tuple-by-tuple and component-by-component, and ValueRanges, which iterate element-by-element using AOS-ordering.
>
> I've linked a blog post describing them in more detail, and a merge request available to play with / review / nitpick for anyone interested in doing so =)
>
> https://blog.kitware.com/c11-for-range-support-in-vtk/
> https://gitlab.kitware.com/vtk/vtk/merge_requests/4826
>

This is awesome Allie.

Any plans for something similar for vtkCollection*?

Elvis

> Allie
> _______________________________________________
> 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:
> https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Allie Vacanti
On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik <[hidden email] wrote:
Any plans for something similar for vtkCollection*?

Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK. 

It'd have a similarly usage as the array iterators:

vtk[...]Collection *myCollection = ...;
for (auto item : vtk::Range(myCollection)) { ... }

I'll put this on my list to look at in my spare cycles.  Good suggestion!

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Sebastien Jourdain via vtk-developers
Nice blog.

On 10 Nov 2018 12:00 a.m., Allie Vacanti <[hidden email]> wrote:
On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik <[hidden email] wrote:
Any plans for something similar for vtkCollection*?

Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK. 

It'd have a similarly usage as the array iterators:

vtk[...]Collection *myCollection = ...;
for (auto item : vtk::Range(myCollection)) { ... }

I'll put this on my list to look at in my spare cycles.  Good suggestion!


_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

David E DeMarle
+1 for the idea of converting vtk collections into stl conventions. 

On Fri, Nov 9, 2018, 6:49 AM Todd via vtk-developers <[hidden email]> wrote:
Nice blog.

On 10 Nov 2018 12:00 a.m., Allie Vacanti <[hidden email]> wrote:
On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik <[hidden email] wrote:
Any plans for something similar for vtkCollection*?

Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK. 

It'd have a similarly usage as the array iterators:

vtk[...]Collection *myCollection = ...;
for (auto item : vtk::Range(myCollection)) { ... }

I'll put this on my list to look at in my spare cycles.  Good suggestion!

_______________________________________________
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:
https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Will Schroeder-2
In reply to this post by Allie Vacanti
Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK.

As the blog hints at, one concern which is readily apparent when perusing VTK source code is the number of options available to do the same thing. I'd really like to see consolidation at some point. Many of our *core* algorithms like contouring (whether you are looking at marching cubes, synchronized templates or flying edges) use the old template macro dispatch, while classes like vtkContourGrid use virtual methods etc. and so on. If you are a budding visualization enthusiast or algorithm writer/developer this can be quite confusing, as the code is increasingly peppered with complexity -- a potential barrier to new developers and community growth.

Finally, the examples used in the blog to demonstrate the different iterators are necessarily simple. However I'd like to see how these various approaches work in more complex algorithms when data flies in many simultaneous directions :-) 

But maybe the reality is that we need multiple options for good reasons e.g., to address increasing computing complexity.... but I'd like to explicitly agree this is the case rather than leaving a trail of alternate implementations. So is there a roadmap for consolidation etc?

Best,


On Thu, Nov 8, 2018 at 5:21 PM Allie Vacanti <[hidden email]> wrote:
Hi folks,

I've written a set of STL-compatible utilities that allow vtkDataArrays to be efficiently used with STL algorithms as well as with C++11 for-range syntax. This consists of TupleRanges, which iterate through an array tuple-by-tuple and component-by-component, and ValueRanges, which iterate element-by-element using AOS-ordering.

I've linked a blog post describing them in more detail, and a merge request available to play with / review / nitpick for anyone interested in doing so =)

https://blog.kitware.com/c11-for-range-support-in-vtk/
https://gitlab.kitware.com/vtk/vtk/merge_requests/4826

Allie
_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers



--
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
[hidden email]
http://www.kitware.com
(518) 881-4902

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Allie Vacanti
On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder <[hidden email]> wrote:
Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK.

As the blog hints at, one concern which is readily apparent when perusing VTK source code is the number of options available to do the same thing. I'd really like to see consolidation at some point. Many of our *core* algorithms like contouring (whether you are looking at marching cubes, synchronized templates or flying edges) use the old template macro dispatch, while classes like vtkContourGrid use virtual methods etc. and so on. If you are a budding visualization enthusiast or algorithm writer/developer this can be quite confusing, as the code is increasingly peppered with complexity -- a potential barrier to new developers and community growth.

Finally, the examples used in the blog to demonstrate the different iterators are necessarily simple. However I'd like to see how these various approaches work in more complex algorithms when data flies in many simultaneous directions :-) 

But maybe the reality is that we need multiple options for good reasons e.g., to address increasing computing complexity.... but I'd like to explicitly agree this is the case rather than leaving a trail of alternate implementations. So is there a roadmap for consolidation etc?

There is not a plan to deprecate the older methods at this point. In the past, changes to the vtkDataArray API have been frowned upon as they can force external (and internal!) code to require significant and expensive refactoring effort to use the new methods. My goal with this post is to provide education and insight into the various ways to access array data, and compare their good and bad traits as fairly as possible.

A lot of the current preferred techniques build upon the older APIs and use them under the covers -- they just package them up in ways that are easier to use. For instance, the new iterators use vtkDataArrayAccessor, GetPointer, and VTK_ASSUME internally. The Accessors internally use both the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily view the newer techniques as full-on replacements for the old APIs, but rather layers on top of them that simplify the usage of the older techniques, especially in performance-critical and generic contexts.

The older APIs still have merit, IMO:

vtkDataArray APIs are slow, but easy to write. They're just fine for fast prototyping and proof of concepts, and situations where a fast execution path is not as important as having broad support for any array that comes in. It's also critical to have for the fall-back pattern when a dispatch fails.

vtkGenericDataArray API is the cornerstone of all of modern fast-path code.

Accessors can and probably should be discouraged once the iterators are in. They still may be more convenient, however, when dealing with more complex traversals and access patterns that would be cumbersome using iterators.

AOS::GetPointer and SOA::GetComponentArray are still extremely useful for writing very low-level optimized code in the rare cases where having separately tuned implementations for SOA vs. AOS would pay off.

However....vtkDataArray::GetVoidPointer() should be chucked in the bin, IMO. It made sense when it was added, but it relies on the AOS assumption, which is no longer guaranteed. There would be significant internal and external development cost to move away from it, so idk what to do about that one. Maybe just permanent deprecation, or hide it behind a compatibility layer? We'd need a decent sized chunk of funding to migrate VTK itself away from it first.

So, rather than deprecating and removing old methods, creating simpler layers on top of them and providing reference / educational resources seems like the better option to me.

As for more complex examples, there are absolutely cases where iterator APIs are not going to be the best choice. For complicated code doing multiple lookups and random accesses, using a more verbose / explicit API will lead to much more maintainable, readable, and debuggable code. The array APIs or Accessors would still be preferred in those cases.

But for simple traversals, or work that could be accomplished by leveraging the STL? Iterators are the way to go :-)

Allie

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Will Schroeder-2
Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten using the preferred approach of your choosing :-) (or alternatively point us to good, non-trivial examples). Along with benchmarking to see what the impacts are... IMO code examples like this can go a long way to helping others do the right thing.

On Fri, Nov 9, 2018 at 10:51 AM Allie Vacanti <[hidden email]> wrote:
On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder <[hidden email]> wrote:
Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK.

As the blog hints at, one concern which is readily apparent when perusing VTK source code is the number of options available to do the same thing. I'd really like to see consolidation at some point. Many of our *core* algorithms like contouring (whether you are looking at marching cubes, synchronized templates or flying edges) use the old template macro dispatch, while classes like vtkContourGrid use virtual methods etc. and so on. If you are a budding visualization enthusiast or algorithm writer/developer this can be quite confusing, as the code is increasingly peppered with complexity -- a potential barrier to new developers and community growth.

Finally, the examples used in the blog to demonstrate the different iterators are necessarily simple. However I'd like to see how these various approaches work in more complex algorithms when data flies in many simultaneous directions :-) 

But maybe the reality is that we need multiple options for good reasons e.g., to address increasing computing complexity.... but I'd like to explicitly agree this is the case rather than leaving a trail of alternate implementations. So is there a roadmap for consolidation etc?

There is not a plan to deprecate the older methods at this point. In the past, changes to the vtkDataArray API have been frowned upon as they can force external (and internal!) code to require significant and expensive refactoring effort to use the new methods. My goal with this post is to provide education and insight into the various ways to access array data, and compare their good and bad traits as fairly as possible.

A lot of the current preferred techniques build upon the older APIs and use them under the covers -- they just package them up in ways that are easier to use. For instance, the new iterators use vtkDataArrayAccessor, GetPointer, and VTK_ASSUME internally. The Accessors internally use both the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily view the newer techniques as full-on replacements for the old APIs, but rather layers on top of them that simplify the usage of the older techniques, especially in performance-critical and generic contexts.

The older APIs still have merit, IMO:

vtkDataArray APIs are slow, but easy to write. They're just fine for fast prototyping and proof of concepts, and situations where a fast execution path is not as important as having broad support for any array that comes in. It's also critical to have for the fall-back pattern when a dispatch fails.

vtkGenericDataArray API is the cornerstone of all of modern fast-path code.

Accessors can and probably should be discouraged once the iterators are in. They still may be more convenient, however, when dealing with more complex traversals and access patterns that would be cumbersome using iterators.

AOS::GetPointer and SOA::GetComponentArray are still extremely useful for writing very low-level optimized code in the rare cases where having separately tuned implementations for SOA vs. AOS would pay off.

However....vtkDataArray::GetVoidPointer() should be chucked in the bin, IMO. It made sense when it was added, but it relies on the AOS assumption, which is no longer guaranteed. There would be significant internal and external development cost to move away from it, so idk what to do about that one. Maybe just permanent deprecation, or hide it behind a compatibility layer? We'd need a decent sized chunk of funding to migrate VTK itself away from it first.

So, rather than deprecating and removing old methods, creating simpler layers on top of them and providing reference / educational resources seems like the better option to me.

As for more complex examples, there are absolutely cases where iterator APIs are not going to be the best choice. For complicated code doing multiple lookups and random accesses, using a more verbose / explicit API will lead to much more maintainable, readable, and debuggable code. The array APIs or Accessors would still be preferred in those cases.

But for simple traversals, or work that could be accomplished by leveraging the STL? Iterators are the way to go :-)

Allie


--
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
[hidden email]
http://www.kitware.com
(518) 881-4902

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Andras Lasso

> Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten Along with benchmarking

 

Fully agree.

 

I wish there was a +1 button that I could click to show support, instead of littering everyone’s mailbox with yet another email. I hope VTK forum will be available soon.

 

Andras

 

From: vtk-developers <[hidden email]> On Behalf Of Will Schroeder
Sent: Friday, November 9, 2018 11:40 AM
To: Allison Vacanti <[hidden email]>
Cc: vtk-developers <[hidden email]>
Subject: Re: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays

 

Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten using the preferred approach of your choosing :-) (or alternatively point us to good, non-trivial examples). Along with benchmarking to see what the impacts are... IMO code examples like this can go a long way to helping others do the right thing.

 

On Fri, Nov 9, 2018 at 10:51 AM Allie Vacanti <[hidden email]> wrote:

On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder <[hidden email]> wrote:

Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK.

 

As the blog hints at, one concern which is readily apparent when perusing VTK source code is the number of options available to do the same thing. I'd really like to see consolidation at some point. Many of our *core* algorithms like contouring (whether you are looking at marching cubes, synchronized templates or flying edges) use the old template macro dispatch, while classes like vtkContourGrid use virtual methods etc. and so on. If you are a budding visualization enthusiast or algorithm writer/developer this can be quite confusing, as the code is increasingly peppered with complexity -- a potential barrier to new developers and community growth.

 

Finally, the examples used in the blog to demonstrate the different iterators are necessarily simple. However I'd like to see how these various approaches work in more complex algorithms when data flies in many simultaneous directions :-) 

 

But maybe the reality is that we need multiple options for good reasons e.g., to address increasing computing complexity.... but I'd like to explicitly agree this is the case rather than leaving a trail of alternate implementations. So is there a roadmap for consolidation etc?

 

There is not a plan to deprecate the older methods at this point. In the past, changes to the vtkDataArray API have been frowned upon as they can force external (and internal!) code to require significant and expensive refactoring effort to use the new methods. My goal with this post is to provide education and insight into the various ways to access array data, and compare their good and bad traits as fairly as possible.

A lot of the current preferred techniques build upon the older APIs and use them under the covers -- they just package them up in ways that are easier to use. For instance, the new iterators use vtkDataArrayAccessor, GetPointer, and VTK_ASSUME internally. The Accessors internally use both the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily view the newer techniques as full-on replacements for the old APIs, but rather layers on top of them that simplify the usage of the older techniques, especially in performance-critical and generic contexts.

The older APIs still have merit, IMO:

vtkDataArray APIs are slow, but easy to write. They're just fine for fast prototyping and proof of concepts, and situations where a fast execution path is not as important as having broad support for any array that comes in. It's also critical to have for the fall-back pattern when a dispatch fails.

vtkGenericDataArray API is the cornerstone of all of modern fast-path code.

Accessors can and probably should be discouraged once the iterators are in. They still may be more convenient, however, when dealing with more complex traversals and access patterns that would be cumbersome using iterators.

AOS::GetPointer and SOA::GetComponentArray are still extremely useful for writing very low-level optimized code in the rare cases where having separately tuned implementations for SOA vs. AOS would pay off.

However....vtkDataArray::GetVoidPointer() should be chucked in the bin, IMO. It made sense when it was added, but it relies on the AOS assumption, which is no longer guaranteed. There would be significant internal and external development cost to move away from it, so idk what to do about that one. Maybe just permanent deprecation, or hide it behind a compatibility layer? We'd need a decent sized chunk of funding to migrate VTK itself away from it first.

So, rather than deprecating and removing old methods, creating simpler layers on top of them and providing reference / educational resources seems like the better option to me.

As for more complex examples, there are absolutely cases where iterator APIs are not going to be the best choice. For complicated code doing multiple lookups and random accesses, using a more verbose / explicit API will lead to much more maintainable, readable, and debuggable code. The array APIs or Accessors would still be preferred in those cases.

But for simple traversals, or work that could be accomplished by leveraging the STL? Iterators are the way to go :-)

Allie


 

--

William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
[hidden email]
http://www.kitware.com
(518) 881-4902


_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Allie Vacanti
In reply to this post by Will Schroeder-2
On Fri, Nov 9, 2018 at 11:39 AM Will Schroeder <[hidden email]> wrote:
Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten using the preferred approach of your choosing :-) (or alternatively point us to good, non-trivial examples). Along with benchmarking to see what the impacts are... IMO code examples like this can go a long way to helping others do the right thing.

From the a quick glance at the vtkMarchingCubes code, this would actually be a decent candidate for the iterators. It would take some serious refactoring, but it's essentially four locations in the scalar array moving sequentially through the data simultaneously -- something that could be modeled with iterators fairly easily.

I agree, some more "real life" examples would be useful, right now it's just a matter of finding the cycles to undertake something like this =)

Allie

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Will Schroeder-2
I think (at times I am guilty of this I'm afraid) that we do not do enough to include the broader VTK community. We may not have funding and/or time at the moment at Kitware, but the VTK community includes many very talented non-KW people who can bring their own resources to the table. If together we agree on the challenges, and then "teach" others as necessary, then I have no doubt we can get a lot more done that we might think :-)

On Fri, Nov 9, 2018 at 12:21 PM Allie Vacanti <[hidden email]> wrote:
On Fri, Nov 9, 2018 at 11:39 AM Will Schroeder <[hidden email]> wrote:
Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten using the preferred approach of your choosing :-) (or alternatively point us to good, non-trivial examples). Along with benchmarking to see what the impacts are... IMO code examples like this can go a long way to helping others do the right thing.

From the a quick glance at the vtkMarchingCubes code, this would actually be a decent candidate for the iterators. It would take some serious refactoring, but it's essentially four locations in the scalar array moving sequentially through the data simultaneously -- something that could be modeled with iterators fairly easily.

I agree, some more "real life" examples would be useful, right now it's just a matter of finding the cycles to undertake something like this =)

Allie


--
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
[hidden email]
http://www.kitware.com
(518) 881-4902

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Allie Vacanti
In reply to this post by David E DeMarle
On Fri, Nov 9, 2018 at 8:45 AM David E DeMarle <[hidden email]> wrote:
+1 for the idea of converting vtk collections into stl conventions. 

et voila: 
for (auto item : vtk::Range(collection))
{
  // item is a vtkObject*.
}

vtkRendererCollection *renCollection = ...;
for (auto item : vtk::Range(renCollection))
{
  // item is a vtkRenderer*. Type deduction works for all
  // collection types that define a GetNextItem() method
  // with a specialized type.
}

This design leaves the door open for other usages of vtk::Range(iterable) in the future. vtkCellIterators come to mind...

Allie
 
On Fri, Nov 9, 2018, 6:49 AM Todd via vtk-developers <[hidden email]> wrote:
Nice blog.

On 10 Nov 2018 12:00 a.m., Allie Vacanti <[hidden email]> wrote:
On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik <[hidden email] wrote:
Any plans for something similar for vtkCollection*?

Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK. 

It'd have a similarly usage as the array iterators:

vtk[...]Collection *myCollection = ...;
for (auto item : vtk::Range(myCollection)) { ... }

I'll put this on my list to look at in my spare cycles.  Good suggestion!

_______________________________________________
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:
https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Elvis Stansvik
Den tis 13 nov. 2018 kl 18:25 skrev Allie Vacanti <[hidden email]>:

>
> On Fri, Nov 9, 2018 at 8:45 AM David E DeMarle <[hidden email]> wrote:
>>
>> +1 for the idea of converting vtk collections into stl conventions.
>
>
> et voila:
>
> https://gitlab.kitware.com/vtk/vtk/commit/dd3fce7815ff2285a7b93e2ee5a642cdcd066626?merge_request_iid=4826
>
> vtkCollection *collection = ...;
> for (auto item : vtk::Range(collection))
> {
>   // item is a vtkObject*.
> }
>
> vtkRendererCollection *renCollection = ...;
> for (auto item : vtk::Range(renCollection))
> {
>   // item is a vtkRenderer*. Type deduction works for all
>   // collection types that define a GetNextItem() method
>   // with a specialized type.
> }
>
> This design leaves the door open for other usages of vtk::Range(iterable) in the future. vtkCellIterators come to mind...

Wow, all-inclusive service at this place! In the same MR even. Let me
see, what should I think up next.. :)

Elvis

>
> Allie
>
>>
>> On Fri, Nov 9, 2018, 6:49 AM Todd via vtk-developers <[hidden email]> wrote:
>>>
>>> Nice blog.
>>>
>>> On 10 Nov 2018 12:00 a.m., Allie Vacanti <[hidden email]> wrote:
>>>
>>> On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik <[hidden email] wrote:
>>>
>>> Any plans for something similar for vtkCollection*?
>>>
>>>
>>> Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK.
>>>
>>> It'd have a similarly usage as the array iterators:
>>>
>>> vtk[...]Collection *myCollection = ...;
>>> for (auto item : vtk::Range(myCollection)) { ... }
>>>
>>> I'll put this on my list to look at in my spare cycles.  Good suggestion!
>>>
>>>
>>> _______________________________________________
>>> 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:
>>> https://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:
> https://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:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Allie Vacanti
On Tue, Nov 13, 2018 at 1:53 PM Elvis Stansvik <[hidden email]> wrote:
Wow, all-inclusive service at this place! In the same MR even. Let me
see, what should I think up next.. :)

It was a good idea! And much easier/faster to write since performance here isn't nearly as critical as the DataArray case ;)

_______________________________________________
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:
https://public.kitware.com/mailman/listinfo/vtk-developers