Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
refactor template instantiation #1516
This is another way to fix #1504 that works for macOS, and probably others.
Instead of including fc/smart_ref_impl.hpp, this fix permits the template to generate the specific copy constructor that is needed.
I am unable to test on the originally reported platform (openSUSE 15.04) , as I do not have that environment.
Note: I threw in another fix that is not related to the above, but does allow for compilation on macOS. I thought it too small for a separate PR, but it is in a separate commit (regarding size_t to uint64_t) should others think it better to separate them.
I have looked through the code, and unless I am missing something big, this smart_ref stuff is of little use. It is only used in fee_schedule.
Of course, because of its use there, there needs to be code to serialize and de-serialize it. Plus the actual template definitions. And you will need to include the smart_ref header everywhere you use fee_schedule.
It seems like a whole lot of hoops to do what I think a smart pointer could do.
Then there are problems with the template on mac. It seems to have been causing problems on that platform for a while, as a static "tmp" of smart_ref<fee_schedule> was added a few years ago to allow mac to compile it.
In an attempt to fix recent mac issues, adding a simple forward-declare causes problems with the overloaded ! operator.
All of the above makes me think about ripping it out. But two issues appear:
Looking for input/opinions.
Note: I can fix the mac overloaded ! by doing a specialization. It is an easy fix, but the above questions remain.
Hm, this looks somewhat useless indeed.