mercredi 24 mars 2021

design pattern for links

I have a bunch of functors that take some data and build new ones when operator() is invoked. The input data of the functors may be some "local" data to the functor, some "global static" data, or the result of another functor.

In the first two cases, the functor has full control of the lifecycle of the data (either local or guaranteed to last forever). The problem comes with the last case, since functors may be deleted, modified and re-run, leading to reallocation or deletion.

I was thinking of developing a single interface of a Link, that basically acts as a proxy for the data. Something like:

template<typename T>
class Link {
  T & get();
};

Maybe, provide specializations for Persistent and Builded types and, in the last case, also provide methods to query the memory state of the data (broken link) or to ask who is supposed to build it.

How this kind of problems is generally approached? Should I also create an Output class whose instances are owned by the functors that actually build that data?

Bonus question : how to correctly define operator< to allow the use of associative containers, without risking to lose data?

std::map<Link<Key>,Value>

weak_ptr do not allow it

Aucun commentaire:

Enregistrer un commentaire