Re: flyweights, nested flyweights and shared libraries

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2021-02-20 15:21:36

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