буферы протокола — изменение элемента существующего сообщения protobuf в переполнении стека

Мне было просто интересно, почему никто не прошел через проблему, с которой я столкнулся в последнее время в связи с Google Protobufs, но после интенсивного поиска в Google, прочитав документацию по справочной странице Google и выполнив поиск в Stackoverflow-DB, я не нашел решения.

Я использую proto2-c ++ — API на Ubuntu 14.04.3 LTS, компилируя с помощью gcc / g ++ поверх cmake-файлов.

У меня есть приложение, которое читает двоичные (сериализованные) сообщения буфера протокола Google из файла. Целью программы является отправка сообщений (без десериализации) в другое приложение, которое приступает к обработке фактических данных.

Теперь я хотел бы изменить некоторые сообщения, прочитанные из файла, чтобы я мог проверить функциональность второго приложения. К сожалению, мое сообщение содержит много вложенных сообщений, поэтому после десериализации мне нужно вызвать что-то вроде

message().a().b().c()....x().value();

уметь работать с актуальными данными.

Мой вопрос сейчас заключается в том, как я могу изменить значение x без создания другого сообщения типа message где я также должен создать все вложенные сообщения (a,b,c...) и назначить их соответствующему предшественнику, как в следующем псевдокоде ?!

a = new a();
b = new b();
c = new c();
...
v = new v();
w = new w();
x = new x();
x.set_value();
w.set_allocated_x_value(x);
v.set_allocated_w_value(w);
...
a.set_allocated_b_value(b);
message.set_allocated_a_value(a);

...
/* forward message to second application */
...delete x;
delete w;
...
delete a;

Очевидно, что это не возможно позвонить set_value прямо на message-объекты, соответственно, его подобъекты, такие как message().a().b().c()....x().set_value(); , как можно было бы нарушить требования const автоматически сгенерированных protobuf-сообщений, где нельзя вызывать метод setter для объекта const: ошибка: передача xxx в качестве аргумента ‘this’ в xxx отбрасывает квалификаторы

Буду признателен за любое креативное решение, чтобы избежать реализации рекурсивного new-set_allocated-delete код, размещенный выше.

заранее спасибо