Hello Joaquín,
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?
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
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
From: Boost-users <boost-users-boun...@lists.boost.org> On Behalf Of Joaquin M
López Muñoz via Boost-users
Sent: zaterdag 20 februari 2021 16:22
To: boost-users@lists.boost.org
Cc: Joaquin M López Muñoz <joaquinlopezmu...@gmail.com>
Subject: Re: [Boost-users] flyweights, nested flyweights and shared libraries
El 19/02/2021 a las 16:54, Andreas Buykx via Boost-users escribió:
I want to use boost::flyweight to capture some structures containing const data.
The documentation states that if flyweights are exported across shared library
boundaries
that the intermodule holder should be used.
Since my flyweights are all created in the same shared library I would prefer
to use the
static holder but I keep getting crashes.
It is not only necessary that all flyweights are created in the same DLL: they
must also
be destroyed within that DLL. I guess that's the problem you're experiencing.
I tried the intermodule holder but I'm having trouble compiling my sources with
that.
Can you provide more info on the kind of problems you're running into?
intermodule_holder tests successfully in Linux, Mac and Windows platforms.
I presume it is Windows you use.
So my thinking was to wrap all flyweight types in accessor classes which are
exposed instead, and the
accessor classes create the flyweights within the same shared library to store
the data.
Would that be a valid approach?
I think your first option should be to make intermodule_holder work. That said,
the
approach you outline below in your mail looks OK, as the lifetime of flyweight
objects
is handled entirely within DLL-specific exported functions. A simpler approach
would be
to define a wrapper around boost::flyweight:
// template class to be instantiated *only*
// within your exporting DLL
template<typename T>
struct DLLEXPORT dll_flyweight:boost::flyweight<T>
{
using boost::flyweight<T>::flyweight;
};
Also, is it possible to have nested flyweights (when they are wrapped by
accessor classes)?
And would that cause any additional problems in the above scenario?
I don't see any problem with that.
Best,
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
