Clean up templating in generate sides code

[JustinPrivitera]

Closes #1105

Now that we have data accessors and data arrays, a lot of the templating in the generate sides code was able to be removed/simplified.

Also adds the assignment operator to the data accessor.

The tests all pass.

[cyrush]

Looks good - Small suggestion related to the accessor types, we want to uses the 64-bit ones (float64_accessor and int64_accessor)

This cleans things up nicely!

[JustinPrivitera]

@cyrush are there any plans to allow

float64_accessor myaccessor; // I am not initializing this accessor here but plan to later on

without a compiler warning (or was it an error? I don't remember)

[cyrush]

@cyrush are there any plans to allow

float64_accessor myaccessor; // I am not initializing this accessor here but plan to later on

without a compiler warning (or was it an error? I don't remember)

We fixed so you can you can do this now:

(as of #1080)

[JustinPrivitera]

I got worried when I saw this:

[ 45%] Building CXX object libs/blueprint/CMakeFiles/conduit_blueprint.dir/conduit_blueprint_mesh.cpp.o
/usr/workspace/justin/conduit_builds/develop/conduit/src/libs/blueprint/conduit_blueprint_mesh.cpp: In function ‘void conduit::blueprint::detail::map_fields_to_generated_sides(const conduit::Node&, const conduit::Node&, const conduit::Node&, const conduit::Node&, const conduit::Node&, const conduit::Node&, conduit::Node&, const std::vector<std::__cxx11::basic_string<char> >&, const string&)’:
/usr/workspace/justin/conduit_builds/develop/conduit/src/libs/blueprint/conduit_blueprint_mesh.cpp:5381:64: warning: implicitly-declared ‘conduit::DataAccessor<double>& conduit::DataAccessor<double>::operator=(const conduit::DataAccessor<double>&)’ is deprecated [-Wdeprecated-copy]
 5381 |                     volume_ratio = volumes_info["ratio"].value();
      |                                                                ^
In file included from /usr/workspace/justin/conduit_builds/develop/conduit/src/libs/conduit/conduit_node.hpp:35,
                 from /usr/workspace/justin/conduit_builds/develop/conduit/src/libs/conduit/conduit.hpp:25,
                 from /usr/workspace/justin/conduit_builds/develop/conduit/src/libs/blueprint/conduit_blueprint_mcarray.hpp:17,
                 from /usr/workspace/justin/conduit_builds/develop/conduit/src/libs/blueprint/conduit_blueprint_mesh.cpp:33:
/usr/workspace/justin/conduit_builds/develop/conduit/src/libs/conduit/conduit_data_accessor.hpp:55:9: note: because ‘conduit::DataAccessor<double>’ has user-provided ‘conduit::DataAccessor<T>::DataAccessor(const conduit::DataAccessor<T>&) [with T = double]’
   55 |         DataAccessor(const DataAccessor<T> &accessor);
      |         ^~~~~~~~~~~~

[JustinPrivitera]

It's your call - do you want me to remove a float64* to replace it with a float64_accessor at the cost of adding this warning to the build? Or should I leave as is?

[cyrush]

I see -- it looks like we need to add the assignment op to the DataAccessor.

Can you add this? We can follow the example from the DataArray class

conduit/src/libs/conduit/conduit_data_array.hpp

Line 66 in 5aef054

DataArray<T> &operator=(const DataArray<T> &array);

conduit/src/libs/conduit/conduit_data_array.cpp

Line 80 in 5aef054

DataArray<T>::operator=(const DataArray<T> &array)

[JustinPrivitera]

done

[cyrush]

Awesome!

Extended thought exercise:

What if we could write to a float64_accessor, such that we don't need T *values_array?

[JustinPrivitera]

Do you mean a float64_array?

I thought about that. For vertex associated and volume dependent fields, we made the choice to always write to float64 since we need to do some extra calculations to figure out what the right values should be. Two years ago, we also made the choice that if a field was neither vertex associated nor volume dependent, we would make sure the new field honored the original field's type.

While I was going through this earlier today, I considered changing it so that we always write out float64. Then we can do away with templating entirely. What do you think?