I understand. I thought there might be a workaround somewhere; And yes you can say I am defining a new message format, but what I am implementing is an existing standard, so I think it would be best to strictly follow the standard, rather than having to do a lot of external extra validation. But now it seems that I have to.
在 2014年3月30日星期日UTC+8上午4时06分21秒，Oliver写道： > > On 28 March 2014 15:54, Zhiqian Yuan <[email protected] <javascript:>>wrote: > >> Those two fields are string type, but like other integer enumerations, >> they both have a range to set value. So I decide they should be implemented >> as string-valued enum type. But there's no such a thing either in C++ or in >> proto. >> > > There is no such thing as a "string-valued enum type" in the protobuf > world. You can either have an enum field (that happens to have an integer > encoding under the covers, but that doesn't really matter to you); or you > can have a string field and do whatever validation you want externally to > protobuf. > > Are you trying to implement an existing message format, or are you trying > to define a new message format? If you have control over the format, what's > wrong with a standard enum field for these fields? > > Oliver > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
