-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Finalizer class #684
Finalizer class #684
Conversation
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.
All in all it looks fine to me for its purpose but I have a few nitpicks:
- Prefer
using
instead oftypedef
. This is something I have noticed throughout the code base and is a matter of taste but the consensus in the C++ community is to always useusing
since the syntax is more intuitive and it is more powerful (cf. the coreguidelines) - The names
atfinal
andatfinalUnique
are not ideal. They are not verbs and not properly in camelCase. I suggestregister
andregisterUnique
instead. - I don't see a reason why the functions need to be implemented
inline
in the header. Can you move the methods into a source file? - I am not entirely sure about the
run
functionality. I would not expect a destructor-like function to be valid if called twice. So providing this functionally seems like a recipe for bugs. Similarlyclear
looks like an invitation for resource leaks but since the philosophy in the project so far has been "the OS is going to clean up in the end" instead of careful lifetime management, such functionality might be useful. - There are some unnecessary copies of somewhat expensive
std::function
objects but the Finalizer should not be performance critical so it does't really matter.
|
I think template<typename Fn>
static void registrFn(Fn&& fn)
{
auto& fns = functions();
fns.emplace_back(std::forward<Fn>(fn));
} Or with slightly less potential for confusing error messages: static void registrFn(FinalFn fn)
{
auto& fns = functions();
fns.emplace_back(std::move(fn));
} But the added complexity is probably not worth the performance gain here. The second location where to my mind unnecessary copies occur are in Really, it is best to just ignore my comments on performance. We can always do these optimizations later if it ever becomes an issue. Lets just merge this once the other changes are done. |
My design was to mimic |
Merged as part of #674 |
Finalizer class
Fixes #683
Change Description
Adds a finalization class
Finalizer
which is designed to mimicstd::atexit()
, but with more flexibility. The class has astatic
functionfinalize()
, which will execute all of the functions designated to be executed. As withstd::atexit()
, the functions must have a signaturevoid()
.The class also allows the finalization functions to be cleared, to be queried by a
contains(fn)
function, counted and also run without clearing the functions.Test Description
A test is included in this PR.
Documentation Impact
The class functions have Doxygen comments describing them.