I'm building a publish-subscribe class (called SystermInterface), which is responsible to receive updates from its instances, and publish them to subscribers.

Adding a subscriber callback function is trivial and has no issues, but removing it yields an error, because std::function<()> is not comparable in C .

std::vector<std::function<void()> subs;
void subscribe(std::function<void()> f)
{
    subs.push_back(f);
}
void unsubscribe(std::function<void()> f)
{
    std::remove(subs.begin(), subs.end(), f);  // Error
}

I've came down to five solutions to this error:

1. Registering the function using a weak_ptr, where the subscriber must keep the returned shared_ptr alive.
   Solution example at this link.
2. Instead of registering at a vector, map the callback function by a custom key, unique per callback function.
   Solution example at this link
3. Using vector of function pointers. Example
4. Make the callback function comparable by utilizing the address.
5. Use an interface class (parent class) to call a virtual function.
   In my design, all intended classes inherits a parent class called ServiceCore, So instead of registering a callback function, just register ServiceCore reference in the vector.

Given that the SystemInterface class has a field attribute per instance (ID) (Which is managed by ServiceCore, and supplied to SystemInterface by constructing a ServiceCore child instance).

To my perspective, the first solution is neat and would work, but it requires handling at subscribers, which is something I don't really prefer.

The second solution would make my implementation more complex, where my implementation looks as:

using namespace std;
enum INFO_SUB_IMPORTANCE : uint8_t
{
    INFO_SUB_PRIMARY,       // Only gets the important updates.
    INFO_SUB_COMPLEMENTARY, // Gets more.
    INFO_SUB_ALL            // Gets all updates
};

using CBF = function<void(string,string)>;
using INFO_SUBTREE = map<INFO_SUB_IMPORTANCE, vector<CBF>>;

using REQINF_SUBS   = map<string, INFO_SUBTREE>; // It's keyed by an iterator, explaining it goes out of the question scope.
using INFSRC_SUBS   = map<string, INFO_SUBTREE>;
using WILD_SUBS     = INFO_SUBTREE;

REQINF_SUBS infoSubrs;
INFSRC_SUBS sourceSubrs;
WILD_SUBS wildSubrs;

void subscribeInfo(string info, INFO_SUB_IMPORTANCE imp, CBF f) {
    infoSubrs[info][imp].push_back(f);
}
void subscribeSource(string source, INFO_SUB_IMPORTANCE imp, CBF f) { 
    sourceSubrs[source][imp].push_back(f);
}
void subscribeWild(INFO_SUB_IMPORTANCE imp, CBF f) {
    wildSubrs[imp].push_back(f);
}

The second solution would require INFO_SUBTREE to be an extended map, but can be keyed by an ID:

using KEY_T = uint32_t; // or string...
using INFO_SUBTREE = map<INFO_SUB_IMPORTANCE, map<KEY_T,CBF>>;

For the third solution, I'm not aware of the limitations given by using function pointers, and the consequences of the fourth solution.

The Fifth solution would eliminate the purpose of dealing with CBFs, but it'll be more complex at subscriber-side, where a subscriber is required to override the virtual function and so receives all updates at one place, in which further requires filteration of the message id and so direct the payload to the intended routines using multiple if/else blocks, which will increase by increasing subscriptions.

What I'm looking for is an advice for the best available option.

CodePudding user response：

Regarding your proposed solutions:

1. That would work. It can be made easy for the caller: have subscribe() create the shared_ptr and corresponding weak_ptr objects, and let it return the shared_ptr.
2. Then the caller must not lose the key. In a way this is similar to the above.
3. This of course is less generic, and then you can no longer have (the equivalent of) captures.
4. You can't: there is no way to get the address of the function stored inside a std::function. You can do &f inside subscribe() but that will only give you the address of the local variable f, which will go out of scope as soon as you return.
5. That works, and is in a way similar to 1 and 2, although now the "key" is provided by the caller.

Options 1, 2 and 5 are similar in that there is some other data stored in subs that refers to the actual std::function: either a std::shared_ptr, a key or a pointer to a base class. I'll present option 6 here, which is kind of similar in spirit but avoids storing any extra data:

6. Store a std::function<void()> directly, and return the index in the vector where it was stored. When removing an item, don't std::remove() it, but just set it to std::nullptr. Next time subscribe() is called, it checks if there is an empty element in the vector and reuses it:

std::vector<std::function<void()> subs;

std::size_t subscribe(std::function<void()> f) {
    if (auto it = std::find(subs.begin(), subs.end(), std::nullptr); it != subs.end()) {
        *it = f;
        return std::distance(subs.begin(), it);
    } else {
        subs.push_back(f);
        return subs.size() - 1;
    }
}

void unsubscribe(std::size_t index) {
    subs[index] = std::nullptr;
}

The code that actually calls the functions stored in subs must now of course first check against std::nullptrs. The above works because std::nullptr is treated as the "empty" function, and there is an operator==() overload that can check a std::function against std::nullptr, thus making std::find() work.

One drawback of option 6 as shown above is that a std::size_t is a rather generic type. To make it safer, you might wrap it in a class SubscriptionHandle or something like that.

As for the best solution: option 1 is quite heavy-weight. Options 2 and 5 are very reasonable, but 6 is, I think, the most efficient.