El 23/02/2021 a las 10:59, Andreas Buykx via Boost-users escribió:
Hello Joaquín,
Hi, please don't top-post, see: https://www.boost.org/community/policy.html#quoting
Thanks for your help. This morning it dawned on me what you meant with the remark about the destruction: I implemented all constructors as explicit default in the cpp-file but I had forgotten to do that for the destructor. Now everything runs like a breeze, except for one situation where I get an assertion:
boost::flyweights::detail::recursive_lightweight_mutex::scoped_lock::scoped_lock(boost::flyweights::detail::recursive_lightweight_mutex &): Assertion `pthread_mutex_lock(&m_)==0' failed.
This exception is raised while destroying the nested flyweight wrapper from the nesting flyweight wrapper, but only in one of my many test cases where these flyweight wrappers are used. Do you have any suggestions on why this might happen?
Umm.. Do you have any *global* static variable of type nesting_flyweight? If so, you may be running into the sort of static data initialization issues described at: https://www.boost.org/ibs/flyweight/doc/tutorial/technical.html#static_init To see if this is the problem, insert static your_nested_flyweight_type::initializer fwinit; before the potentially offending global varable.
Regarding the use of intermodule_holder I mistook a link error for a compile error:
/opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/ld: Test/appz/ppf/unittests/model/results/CMakeFiles/unittest_PpfModelResultUnitTest.dir/PpfResultCaseUnitTest.cpp.o: undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
//lib64/librt.so.1: error adding symbols: DSO missing from command line
I'm no Linux expert, does this article help? https://stackoverflow.com/questions/9923495/undefined-reference-shm-open-alr...
All that aside: you mention that getting intermodule_holder is the preferred option, but given that it’s “… |intermodule_holder| is considerably more onerous than |static_holder| in terms of compilation times and introduces a non-negligible overhead at program start-up …”, isn’t wrapping the flyweight in an accessor class (especially your templated construct) at least as good an option that maybe deserves a mention in the documentation?
I'm not sure this is robust enough for general use. What happens if two different modules libA and libB both export the same, say, dll_flyweightstd::string type?
Thanks again for your help,
Andreas
Joaquín M López Muñoz