Использование объектов protobuf в качестве ключа в std :: map

Question

Я новичок в концепции буферов протокола и имею под рукой задачу, которую можно решить, если я использую объект protobuf в качестве ключей в std::map.

Я знаю, что для использования объекта protobuf в качестве ключа мне нужно предоставить собственный компаратор для std::map для поддержания порядка ключей.

У меня есть два вопроса на данный момент:

1. Есть ли какая-нибудь служебная функция / класс в google / protobuf / util, которая перегружает оператор меньше для сравнения двух сообщений protobuf? то есть что-то похожее на это.

bool operator<(google::protobuf::Message m1, google::protobuf::Message m2){
    // compare the protobuf messages
    // and finally return the value
    return value;
} 

2. Есть ли потенциальные побочные эффекты, о которых я мог бы знать, которые могут возникнуть в результате использования объекта protobuf в качестве ключа?

Answer 1

Я предлагаю лучше использовать std::unordered_map, а не std::map, если вы не заботитесь о заказе.Это не только оптимально, но и менее подвержено ошибкам.В случае реализации компаратора вам необходимо убедиться, что Message m1 больше Message m2 и Message m2 больше Message m3, тогда Message m1 больше Message m3.(упомяну, поскольку это не было понятно из вашего определения).

Вы можете использовать MessageDifferencer в качестве замены std:equal_to.См. Также ответы по адресу Сравнение буферов протокола Google

Однако, поскольку вы правильно указали, что эквивалента std::hash нет, вам потребуется предоставить собственную хэш-функцию.Пожалуйста, обратитесь к PR-2066 и PR-2304 , которые обсуждают об этой отсутствующей функциональности.

Из запроса на получение цитирование xfxyjwf :

Не очень хорошая идея использовать прото-сообщение в качестве ключей, потому что они не являются типами истинных значений.При наличии неизвестных полей два одинаковых сообщения в одном двоичном файле могут рассматриваться как разные другим, и, следовательно, два разных двоичных файла могут получить два разных unordered_map <> даже при одинаковых входных данных (если хеш-функция реализована с использованием MessageDifferencer),Вероятно, лучше написать свою собственную хеш-функцию, которая имеет желаемое поведение, а не отвечать на универсальную.

Если у вас нет неизвестных полей, универсальная хеш-функция должна работать нормально.