Ok, well then just read out 4 bytes first in java and they get your 17 8 1 ....
0 0 0 18 might be the lenght that you are not reading first.
mike
On Sat, Jul 10, 2010 at 9:50 PM, Maxim Leonovich <lm.b...@gmail.com> wrote:
> I tried to convert msg.ByteSize() to LittleEndian and to BigEndian,
> but that didn't helps.
> I thought, that {0 0 0 18 ... } is the size, but no. Size is 17.
> Look at screens: in C++ I have {17 8 1 26 12 ...}. In Java : {0 0 0 18
> 17 8 1 26 12...}
> But what is {0 0 0 18} ? I have no more IO operations exept in
> Client::send().
>
> On 10 июл, 22:00, "jamesmikedup...@googlemail.com"
> <jamesmikedup...@googlemail.com> wrote:
>> the leading variant in c++ is most likely in the wrong byte order if
>> you are running a x86 machine. as i said, you need to flip them.
>> mike
>>
>>
>>
>>
>>
>> On Sat, Jul 10, 2010 at 8:53 PM, Maxim Leonovich <lm.b...@gmail.com> wrote:
>> > I watched on both buffers: they are similar, but in C++ I can't find a
>> > leading Variant32 with size, when in Java it exists. The rests of
>> > buffers are identical.
>> >http://pic4.ru/8337
>> >http://pic4.ru/8338
>> >http://pic4.ru/8339
>>
>> > On 10 июл, 19:33, Evan Jones <ev...@mit.edu> wrote:
>> >> On Jul 10, 2010, at 7:47 , Maxim Leonovich wrote:
>>
>> >> > ArrayOutputStream(buffer,msg.ByteSize() + 4,sizeof(char));
>>
>> >> The documentation states:
>>
>> >> block_size is mainly useful for testing; in production you would
>> >> probably never want to set it.
>>
>> >> So you should get rid of the "sizeof(char)" part.
>>
>> >> > cos->WriteLittleEndian32(msg.ByteSize()); //Tryed
>> >> > "WriteVariant32", didn't help
>> >> > msg.SerializeToCodedStream(cos);
>>
>> >> If you want to use Java's .parseDelimitedFrom, you *must* use
>> >> WriteVarint32, because that is the format it expects the length
>> >> prefix. In this case, you'll need to call ArrayOutputStream::
>> >> ByteCount() to figure out how many bytes were actually serialized.
>>
>> >> You also probably should create the ArrayOutputStream and
>> >> CodedOutputStream on the stack, rather than using new. This will be
>> >> slightly faster.
>>
>> >> That said, the only issue here that affects correctness is the
>> >> WriteVarint32 part. The rest shouldn't matter unless I missed
>> >> something. You should change your code to do that, then if you are
>> >> still having problems you should try dumping the contents of the
>> >> buffer on both the C++ and the Java side. Maybe the input/output is
>> >> getting messed up somewhere?
>>
>> >> Good luck,
>>
>> >> Evan
>>
>> >> --
>> >> Evan Joneshttp://evanjones.ca/
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Protocol Buffers" group.
>> > To post to this group, send email to proto...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > protobuf+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/protobuf?hl=en.
>>
>> --
>> James Michael DuPont
>> Member of Free Libre Open Source Software Kosova and Albania
>> flossk.org flossal.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@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.
>
>
--
James Michael DuPont
Member of Free Libre Open Source Software Kosova and Albania
flossk.org flossal.org
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@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.
