Should C++ classes contain or be constructed/populated from protocol buffer messages -

for protocol buffers in c++, wondering if better contain protobuf message in class, or have constructed , populate external protobuf message.

i not find examples describing best practices case. i'm particular worried performance differences between 2 designs.

in processing, have cases going read few fields message , route message process (possibly manipulating message before sendind out), , other cases objects have long lifetime , used many times before being serialized again. in first case, operate directly on protobuf message , not need class, execpt fit existing interface.

here example message:

package example; message example {   optional string name = 1;   optional uint32 source = 2;   optional uint32 destination = 3;   optional uint32 value_1 = 4;   optional uint32 value_2 = 5;   optional uint32 value_3 = 6; } 

i see 1 of following designs class. know these classes aren't doing else accessing data, that's not i'm trying focus on question.

---

composition

class widget {  public:   widget() : message_() {}   widget(const example::example& other_message)    : message_(other_message) {}     const example::example& getmessage() const   { return message_; }    void populatemessage(example::example& message) const   { message = message_; }    // example inspectors filled out...   std::string getname() const   { return message_.name(); }    uint32_t getsource() const;   { return message_.source(); }    uint32_t getdestination() const;   uint32_t getvalue1() const;   uint32_t getvalue2() const;   uint32_t getvalue3() const;    // example mutators filled out...   void setname(const std::string& new_name)   { message_.set_name(new_name); }    void setsource(uint32_t new_source);   { message_.set_source(new_source); }    void setdestination(uint32_t new_destination);   void setvalue1(uint32_t new_value);   void setvalue2(uint32_t new_value);   void setvalue3(uint32_t new_value);   private:   example::example message_; }; 

---

standard data members

class widget {  public:   widget();   widget(const example::example& other_message)    : name_(other_message.name()),      source_(other_message.source()),      destination_(other_message.destination()),      value_1_(other_messsage.value_1()),      value_2_(other_messsage.value_2()),      value_3_(other_messsage.value_3())   {}    example::example getmessage() const   {     example::example message;     populatemessage(message);     return message;   }    void populatemessage(example::example& message) const   {     message.set_name(name_);     message.set_source(source_);     message.set_value_1(value_1_);     message.set_value_2(value_2_);     message.set_value_3(value_3_);   }    // example inspectors filled out...   std::string getname() const   { return name_; }    uint32_t getsource() const;   { return source_; }    uint32_t getdestination() const;   uint32_t getvalue1() const;   uint32_t getvalue2() const;   uint32_t getvalue3() const;    // example mutators filled out...   void setname(const std::string& new_name)   { name_ = new_name; }    void setsource(uint32_t new_source);   { source_ = new_source; }    void setdestination(uint32_t new_destination);   void setvalue1(uint32_t new_value);   void setvalue2(uint32_t new_value);   void setvalue3(uint32_t new_value);   private:   std::string name_;   uint32_t source_;   uint32_t destination_;   uint32_t value_1_;   uint32_t value_2_;   uint32_t value_3_; }; 

---

there no recognized "best practice" here. have seen plenty of examples of both, , written programs worked both ways. people have strong opinions this, in opinion depends on use case. example, say, if plan forward of data server, makes lot of sense keep protobuf object around. other times have more convenient internal representation -- example, before protobufs added native support maps, if had protobuf represented map repeated list of key/value pairs, might want convert std::map upfront.