JOAQUIN LOPEZ MU?Z wrote:
So, I had no other choice but to implement serialization support for Boost.MultiIndex in an interface intrusive way. The morale of the story is: for rich-state classes where the exact state of an object depends heavily on its past history, non-intrusive serialization can be either algorithmically unfeasible (it is hard or impossible to reconstruct the history from the current state) or potentially less efficient than a interface intrusive approach. This does not mean that the class interface or the serialization support implementation are "broken".
Thx for explaining this. I'd like to go back the the header inclusion dependency issue. The need for internal access isn't a reason why the serialization headers need to be 'included by default'. A friend class/function in separate serialization header could implement the serialization using the internal mechanisms that are otherwise an implementation detail. Jeff