[Bro-Dev] Rethinking Broker's blocking API

Matthias Vallentin vallentin at icir.org
Mon Jan 9 11:34:23 PST 2017


> But not a big deal either way, any of these options sounds fine to me.

This is the synopsis for the slightly adapted message class, no other
changes:

    class message {
    public:
      /// Checks whether a message is a (topic, data) pair.
      /// @returns `true` iff the message contains a (topic, data) pair.
      explicit operator bool() const;

      /// @returns the contained topic.
      /// @pre `static_cast<bool>(*this)`
      const broker::topic& topic() const;

      /// @returns the contained topic.
      /// @pre `static_cast<bool>(*this)`
      const broker::data& data() const;

      /// @returns the contained status.
      /// @pre `!*this`
      const broker::status& status() const;
    };

I opted against a .failed() member in broker::message, because it's up
to the concrete status instance to define failure or a mere status
change. A message is now either a (topic, data) pair or a status
instance. 

To distinguish between the two status, I use operator bool. Since this
is almost the same as a failed() method, I have one last idea: instead
of returning const-references to topic, data, and instances. We could
simply return non-owning const-pointers, which are non-null if and only
if the respective type is active:

    if (auto data = msg.data())
      f(*data)
    else
      g(*msg.status())

I've also updated how to do status/error handling. See the documentation
at http://bro.github.io/broker/comm.html#status-and-error-handling for
details.

    Matthias




More information about the bro-dev mailing list