This is caused by a bug in protoc.exe not generating code correctly. Oddly
enough if I use the debug build of protoc.exe it does generate the code
correctly. So I'm using that until someone can figure out what's wrong
with protoc.exe.
On Friday, August 24, 2012 3:33:56 PM UTC-5, Dave wrote:
>
> On field 24 in the message:
>
> // optional double ExecFee = 24;
> inline bool Order::has_execfee() const {
> return (_has_bits_[0] & 0x00800000u) != 0;
> }
> inline void Order::set_has_execfee() {
> _has_bits_[0] |= 0x00800000u;
> }
> inline void Order::clear_has_execfee() {
> _has_bits_[0] &= ~0x00800000u;
> }
>
> Then on field 25 in the message:
>
> // optional double BuyPowerUsed = 25;
> inline bool Order::has_buypowerused() const {
> return (_has_bits_[0] & 0x11000000u) != 0;
> }
> inline void Order::set_has_buypowerused() {
> _has_bits_[0] |= 0x11000000u;
> }
> inline void Order::clear_has_buypowerused() {
> _has_bits_[0] &= ~0x11000000u;
> }
>
> by the time you get to field 29 in the message you can no longer serialize
> fields beyond field number 28 into your message:
>
> // optional .OXObjects.OrderStates OrderState = 29;
> inline bool Order::has_orderstate() const {
> return (_has_bits_[0] & 0x00000000u) != 0;
> }
> inline void Order::set_has_orderstate() {
> _has_bits_[0] |= 0x00000000u;
> }
> inline void Order::clear_has_orderstate() {
> _has_bits_[0] &= ~0x00000000u;
> }
>
> Something is wrong with the protc.exe that's building the protocol buffers
> generated classes. Has anyone seen this or fixed this issue? I would love
> a fix for this.
>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/protobuf/-/waqvcFHI_x8J.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
