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?

Thanks again for your help,

Andreas