Sounds like a case for a move ctor from what your describing
You have a thing that gets made and it's lifetime needs to be given to something else
I try to avoid all smart pointers
And it sounds like promoting your grid to an xvalue if possible and handing it to your distmatrix would do the trick
maintain an
std::vector of them where? and on which processes?
Or whatever is supposed to hold the lifetime of the grids
Based on your last sentence it sounds like a distributed data structure has a member which represents multiple grids
I would still use move semantics to move generated grids into that vector
what is your aversion to
std::unique_ptr?
I can review but it would require Waiting until Jan 1
the improvement in the interface is substantial enough that it will be worth merging once the dust settles (probably in several more days)
also, I am bundling in a Mathematical Programming Software (MPS) reader in the sparse-direct changeset
easily checking that one gets the same results as http://www.netlib.org/lp/data/minos is useful
it just isn't documented yet I think
it is heavily used within Elemental's Interior Point Methods
see
include/El/solve/FGMRES.hpp for the flexible GMRES implementation
and
include/El/solve/LGMRES.hpp for the left-preconditioned standard GMRES
with that said, the iterative solvers in the library have only existed to the point that they were needed for the more "direct" techniques like the IPMs
not that I am opposed to the iterative solvers improving
Hmm, it seems that the Clang bug response time is not so impressive :-( https://llvm.org/bugs/show_bug.cgi?id=31249