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-already-add-lrt-flag-here
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_flyweight<std::string> type?
Thanks again for your help,
Andreas
Joaquín M López Muñoz
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
