Try&Catch construct for mrcpp::get_func

[ilfreddy]

I would like to implement this feature: [www.cplusplus.com/reference/stdexcept/out_of_range/] for the mrcpp::get_func of FunctionTreeVector.
It would be nice to have such a feature for the XCFunctional stuff, now that I am heavily making use of FunctionTreeVector-s for densities and their gradients.
Would that be OK?

[robertodr]

This should be already available if you access an element of the vector with at() rather than []. It incurs a performance penalty, as it needs to check bounds at every access.

[ilfreddy]

That was also my point. How much should we be concerned with performance at this level? We are talking about a vector of tree structures containing a handful of elements (essentially FunctionTree pointers).

[ilfreddy]

Regarding the example in the link, would it be working if I remove the assignment = 100 in the try statement? In other words, I just want to see if the element is correctly defined, not to assign a value.
@robertodr what was the link of the sandbox you showed us?

[robertodr]

The website is coliru. You need to do something with the result of at() either assign it to a dummy variable or assign a new value to it. How many of this checked accesses you'd need? Why not if (idx > vec.size()) abort()? This should have lower overhead and avoid littering the code with try-catch.

[ilfreddy]

if I place the at() in mrcpp::get_func(), it is only going to be there. But fair enough it is going to be used EVERY TIME. I think I can supersede, also because I do not necessarily need to check for bounds only. Sometimes I need to check that the vector contains the correct number of elements before appending a new one. I guess I need to consult @stigrj to find a good strategy.

[robertodr]

Is this specific to XCFunctional? Can you calculate all these bounds at construction? You can add checks on preconditions and postconditions when entering and before return-ing in the methods of the class.

[robertodr]

Even better, if you can templatize over these conditions you'd like to check. Then it's the compiler checking everything makes sense.

[stigrj]

I think you can safely ignore performance at this level

[ilfreddy]

Yes. It's pretty XCFunctional specific. The class needs to know the densities (unperturbed and perturbed to the nth order for nth-order response calculations). They are built in different parts of the code and then passed to XCFunctional which is then feeding them to XCFun to compute the potentials. So I need to know that when I append a given density to the vector, the vector itself is "sane" (e.g. it contains all lower-order densities).

Concerning templetizing... thanks but my C++ level is well below what you would like me to do here, I'm afraid... :-(

[robertodr]

What I was also trying to say is that in a month or two, you'll have forgotten why you're checking that vector has length 15.

[ilfreddy]

Agree. The current "hack" (awaiting for Stig's counseling) is to pass the index where I want the fcn to be placed. The vector size has to be exactly that index, otherwise I abort. Not pretty, but safe :-)