Be more correct in our noexcept usage.

[drwells]

I noticed this while working on the other one. The default ctor allocates so it's technically not noexcept.

Do we have a policy for this? I don't know if we want to be this pedantic about std::bad_alloc.

[masterleinad]

The most important use noexcept is for selecting interfaces the standard library is using and I don't think that this is particularly relevant for Trilinos vectors anyway.

[bangerth]

Out of curiosity, how did you arrive at looking at this? noexcept specifications are both obscure and, arguably, something we haven't cared much about in the past...

[bangerth]

Are you saying that Epetra_FEVector objects cannot be moved, only copied? And that that is why we need to allocate memory ourselves? If so, why do we have a move constructor to begin with?

[drwells]

I'm not sure what the exact properties of Epetra_FEVectors are but our concern is one level higher - the default constructor for our vector class contains

vector(new Epetra_FEVector(
  Epetra_Map(0, 0, 0, Utilities::Trilinos::comm_self())))

i.e., an invariant maintained by this class is that vector is not nullptr. Hence, even creating an empty object allocates memory.

It's still convenient to have the move ctor since we can swap contents with an allocated (but empty) vector.

[bangerth]

I see about the invariant.

If the noexcept part were important, you can of course always move the pointer from the rhs object, and then use try{...} catch(...){abort();} to allocate an empty vector for the rhs. But I don't care either way -- we can deal with this whenever someone actually needs these move operators to be noexcept.

[bangerth]

Isn't this in essence what you would move clearly express with

Suggested change

	static_cast<Subscriptor &>(*this) = static_cast<Subscriptor &&>(v);
	static_cast<Subscriptor &>(*this) = std::move(static_cast<Subscriptor &>(v));

or

Suggested change

	static_cast<Subscriptor &>(*this) = static_cast<Subscriptor &&>(v);
	this->Subscriptor::operator= (std::move(static_cast<Subscriptor &>(v)));

?

[drwells]

I have no strong feelings either way - I just used the same style I also used in LA::d::V. Mind if I edit the syntax in a followup? std::move() is definitely more readable than the extra &.

[bangerth]

Your call.

[drwells]

There's a bunch of these that can be improved - I'd rather do them all at once in a separate PR.

[bangerth]

Sounds good!

[bangerth]

same here

[drwells]

I looked at this because I wanted to see the state of our other vector move constructors after doing #14969. That class also allocates memory by default so its move ctors are not noexcept. IIRC I noticed the issue originally when clang-tidy suggested move ctors always be noexcept.

Why did I do #14969? In a project I have I use my own Scatter class (which just wraps a DoF renumbering and a LA::d::V) to manage two different parallel data partitions (named 'global' and 'overlap'). This leads to code like

{
  Scatter<double> scatter = this->get_scatter(position_dof_handler);
  scatter.global_to_overlap_start(position, 0, overlap_position);
  scatter.global_to_overlap_finish(position, overlap_position);
  this->return_scatter(position_dof_handler, std::move(scatter));
}

I noticed when profiling that this copied instead of moved because we only had one move ctor for LA::d::V (the move ctor, not move assignment operator) so I patched it here and wrote my own workaround there.