Severity of warnings emitted for memset(...) in small_algebra

[stephanmg]

See below.

/home/stephan/Code/ug4/ugcore/cmake/../../ugcore/ugbase/lib_algebra/small_algebra/small_matrix/../storage/variable_array_impl.h:250:8: warning: ‘void* memset(void*, int, std::size_t)’ clearing an object of type ‘ug::VariableArray2<ug::DenseMatrix<ug::VariableArray2<double> > >::value_type’ {aka ‘class ug::DenseMatrix<ug::VariableArray2<double> >’} with no trivial copy-assignment; use assignment or value-initialization instead [-Wclass-memaccess]
  250 |  memset(new_values, 0, sizeof(T)*newRows*newCols); // todo: think about that

Should I worry about this?

Stephan

[nudelsiebl]

Depending on your usage, yes you have.
I looked into it and if a VariableArray or FixedArray contain non-simple classes (i.e. containing pointers) then resizing them sets the objects, and thus the pointers to zero but does not free memory allocated to them.

In this case his would happen if the outer VariableArray in 'ug::VariableArray2<ug::DenseMatrix<ug::VariableArray2 > >' , or the DenseMatrix gets resized.
As long as nothing resizes any of the classes except the inner VariableArray2 nothing should happen, but it would be better to avoid using constructions as these for now.

@anaegel this and other compiler warnings are produced by Navier-Stokes, maybe this is the origin of the memory leak you are looking for?

I made a branch with a (not yet functional) prototype-fix where I added a set_zero() function and changed resize() so that they work approbiately depending on the type. In this case I used c++17 as 'if constexpr' was not yet introduced.

I could try using c++11, but it would need quite a lot of code duplication using template templates, as a lot of specializations have to be covered. Maybe it is possible using variadic templates, but I am not fit in these.