mirror of
https://gitlab.kitware.com/vtk/vtk-m
synced 2024-09-16 17:22:55 +00:00
d1a4aecc59
We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added. |
||
---|---|---|
.. | ||
1.3 | ||
1.4 | ||
1.5 | ||
array_handle_uniform_random.md | ||
arrayhandlegroupvecvariable.md | ||
binary_search_algorithms.md | ||
buffer.md | ||
ci-script.md | ||
configurable-default-types.md | ||
coordinate-transform-results.md | ||
cuda-no-assert.md | ||
custom_portal_iterators.md | ||
dataset-unique-field-names.md | ||
decorator_resizing.md | ||
deprecate-arrayhandlevirtualcoordinates.md | ||
deprecate-dataset-field-add.md | ||
deprecate-execute-with-policy.md | ||
deprecation.md | ||
filter-specifies-own-field-types.md | ||
flying-edges.md | ||
google_benchmark.md | ||
image_io.md | ||
io_reorganize.md | ||
list-tag-remove-if.md | ||
list.md | ||
mask_and_scatters_3d_scheduling.md | ||
move-std-vector.md | ||
no-cell-op-errors.md | ||
ordered-async-access.md | ||
probe-sets-invalid-value.md | ||
readportalget.md | ||
remove-opengl-rendering-classes.md | ||
scoping-tokens.md | ||
shorter-fancy-array-handle-classnames.md | ||
std_porting_headers.md | ||
tuple.md | ||
vtk-io-in-library.md | ||
write-uniform-rectilinear.md |