-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Libmoinfo rework, part 2 #3155
Libmoinfo rework, part 2 #3155
Conversation
…tructor that is a trivial wrapper around it
…le docstring, delete commented out "obsolete code"
…Base, make the MO array private
…o try inlining it
… and const" This reverts commit 7cf26ab.
…to sopi elements in derived classes
…lear_energy() to get_nuc_E()
… directly accessed, return a const&
…ectly accessed, return a const& for the array or an element
…the const& returning variant
…onst& returning variant
…d and const& returning
… variables are already named _ref to denote reference in a non-programming sense
…d and const& returning
…lled once, inline them
…loads are now gone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this lgtm! Needs a review by someone closer to libmoinfo and mcscf, probably FAE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! @loriab, Francesco is going to be out of commission until June 8th, so I suggest we merge without him. Your call.
Description
This is the continuation of my previous MOInfo PR #3112, with the following general themes:
const&
when necessary, and making a few data membersconst
. Havingconst
members in classes is sometimes considered to be bad form, but AFAIK all of the downsides are already incurred on account ofMOInfoBase
having reference members.The git history on this branch is admittedly a bit messy, I changed my mind about a couple of things. LMK if that is a problem.
The next PR in this series will get to what I originally wanted to achieve and remove uses of the ugly "cast Dimension object to pointer" operators (see #2953) from
libmoinfo.
User API & Changelog headlines
Dev notes & details
MOInfoBase::correlate
is removedMOInfoBase
dtor does is callMOInfoBase::cleanup()
, an empty function. Removed both.MOInfo::free_memory()
into its only caller, theMOInfo
dtormoinfo_mappings.cc
double** scf
MO array and theget_scf_mos()
getter fromMOInfoBase
toMOInfo
and made the array privateMOInfoBase::startup()
into its only caller, theMOInfoBase
ctorMOInfoBase::nmo
toMOInfo
and made it privateconst
and private inMOInfoBase
MOInfoBase::sopi
private, added a protected getter fn to give access in derived classesMOInfoBase::nso
,MOInfoBase::nuclear_energy
andMOInfoBase::irr_labs
privateMOInfoBase
that have previously returned copies ofstd::vector
members now returnconst&
to the vector in the object, avoiding a potential copy.MOInfoBase::silent
is only used in the ctor ofMOInfo,
, I removed it fromMOInfoBase
andMOInfoSCF
MOInfo::get_actv(size_t i)
andMOInfo::get_docc(size_t i)
as both were only called once. Since these overloads are now gone fromMOInfo
, it can now just useget_docc()
andget_actv()
fromMOInfoBase
instead of having to reimplement or explicitly inherit them.Checklist
libmoinfo
Status