Few days I'm trying to send a message from C++ to Java over the
network but unsuccessfully.
I needed to send a several messages over one connection. I'm doing
this:
//C++ side
void MainWindow::client_connected() {
GPSChatMessage msg = GPSChatMessage();
Kenton Varda wrote:
LDFLAGS=-static isn't good enough?
Nope, something along the way eats it.
-O
--
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
I encountered a similar problem with reading the bytes in C++ from
data written in Java.
Solved it by swapping the bytes :
uint32_t magic_number = ntohl(magic_number_);
http://github.com/h4ck3rm1k3/OSM-Osmosis/commit/714be97af12698f83152d2c1d0e407337e82803b
mike
On Sat, Jul 10, 2010 at 1:47
Will it solve the libz.so.1 linking problem?
Thanks,
Jacky
On Sat, Jul 10, 2010 at 3:11 AM, Kenton Varda ken...@google.com wrote:
LDFLAGS=-static isn't good enough?
On Fri, Jul 9, 2010 at 6:08 AM, Oliver Jowett oliver.jow...@gmail.comwrote:
Jacky wrote:
Many thanks! sorry for the late
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.
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 ,
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
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
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
On Wed, Jul 7, 2010 at 2:55 PM, Chuck Knight chuck.a.kni...@gmail.com wrote:
Does anyone have an ECCN (export control number) for this project?
I don't think there is one. What makes you think one is needed? I
thought that export control numbers for software were only required
where cryptography
Hello!
How to find out whether I got whole message or not if I read raw data
from socket?
I use Python.
Regards,
Alex.
--
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
Since an outermost protobuf message does not include either a delimiter or a
length, it is (for this scenario) necessary either to include your *own*
message boundary mechanism, or for single messages just close the stream.
The most common approach seems to be simply to include the length as a
On Sat, Jul 10, 2010 at 11:53 AM, 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
13 matches
Mail list logo
