[protobuf] Message with multiple strings problem

2016-10-07 Thread Chazix
Hello,

I have a message that looks like:

message Connected {
>   sint32 xloc   = 1; // x spawn world position
>   sint32 yloc   = 2; // y spawn world position
>   sint32 zrot   = 3; // z spawn rotation
>   string sector = 4; // sector name (unsure about this)
>   string name   = 5; // player name
>   string pid= 6; // player id
>   string scolor = 7; // ship color
>   string sname  = 8; // ship name
> }


I am attempting to initialize it within my c++ code like this:

>
> GameClientStats& stats = gameClient.GetGameClientStats();
> server::player::Connected connectMessage; // send this to this joining 
> client
> connectMessage.set_name(stats.m_clientName);
> connectMessage.set_pid(stats.m_clientId);
> connectMessage.set_scolor(stats.m_shipColor);
> connectMessage.set_sname(stats.m_shipName);
> connectMessage.set_xloc(stats.m_xPos);
> connectMessage.set_yloc(stats.m_yPos);
> connectMessage.set_zrot(stats.m_zRot);


For some reason as I set my string parameters, the prior strings before it 
gets set to that string value. So, if I do the set_pid the name field will 
also change to the pid. set_scolor the name & pid will be set to the 
s_color. set_sname the name, pid & scolor will change to be the sname. It 
seems like they are all sharing the same string pointer field location.

Am I not initializing my message correctly? Or do I need to do something 
differently here? When I Serialize my messages from a coded stream I get my 
expected message, but manual creation doesn't seem to be working with what 
I'm currently trying to do.

Thank you very much for the information.

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


Re: [protobuf] protobuf::Any Message vs MessageLite interface

2016-10-07 Thread Arpit Baldeva
Thanks for the info.

I feel like without pack/unpack/Is method, the utility of Any will 
diminish. For example, the rpc status proto 
(https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto) 
uses repeated Any field. It'd not be possible to write code like one 
described here 
- https://developers.google.com/protocol-buffers/docs/proto3#any because 
you won't know if it is safe to convert value to a give message. I also 
came across this post after my post which marks the request as a bug 
currently - https://github.com/google/protobuf/issues/1974 

Regarding the future of GetTypeName, though it has overhead, feel like it 
could have many utilities outside of the Any support as well. I don't have 
concrete use case in mind though as I am just starting on protobuf. This 
brings another important question that I was wondering if somebody already 
has data around. There are two options for reducing code bloat. One is Lite 
and another is code_size. I understand that lite reduces code bloat by 
removing descriptors/reflections related code (thereby reducing the library 
size) and code_size reduces the code bloat by generating less code per 
message but puts descriptors/reflectors back in(shared code). And the 
recommendation is to choose code_size option if number of message are much 
higher compared to the overhead caused by the size of lib. Are there any 
benchmarks around what the size of the library is (and lite version) and 
what is the per message overhead saved by the code_size option? And the 
performance drop with code_size option?   

--Arpit



On Friday, October 7, 2016 at 10:56:49 AM UTC-7, Adam Cozzette wrote:
>
> Good question, I'm not much of a mobile developer so hopefully someone 
> with more experience there can chime in. But my thought would be that if 
> you're on mobile and need the performance of lite protos then you would 
> probably want to just read and write Any fields manually instead of using 
> the helper methods that require non-lite. If the extra boilerplate turns 
> out to be excessive, we could look into ways of updating the Any API to 
> make it a little easier to use with lite protos.
>
> On Fri, Oct 7, 2016 at 10:15 AM, Tim Kientzle  > wrote:
>
>>
>> On Oct 7, 2016, at 9:54 AM, 'Adam Cozzette' via Protocol Buffers <
>> prot...@googlegroups.com > wrote:
>>
>> Here's the thing, though: we are actually thinking about removing the 
>> MessageLite::GetTypeName method at some point in the future. Lite protos 
>> are intended primarily for mobile and so in that environment it's important 
>> to keep the binary as small as possible and also avoid including symbols in 
>> the code that's distributed, whereas currently that method requires us to 
>> generate code that includes the message type names. So I think it would be 
>> best to avoid creating another dependency on that GetTypeName() method when 
>> it might be going away in the future.
>>
>>
>> This seems to suggest that you don’t intend to support Any for mobile?
>>
>> Tim
>>
>>
>

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


Re: [protobuf] protobuf::Any Message vs MessageLite interface

2016-10-07 Thread 'Adam Cozzette' via Protocol Buffers
Good question, I'm not much of a mobile developer so hopefully someone with
more experience there can chime in. But my thought would be that if you're
on mobile and need the performance of lite protos then you would probably
want to just read and write Any fields manually instead of using the helper
methods that require non-lite. If the extra boilerplate turns out to be
excessive, we could look into ways of updating the Any API to make it a
little easier to use with lite protos.

On Fri, Oct 7, 2016 at 10:15 AM, Tim Kientzle  wrote:

>
> On Oct 7, 2016, at 9:54 AM, 'Adam Cozzette' via Protocol Buffers <
> protobuf@googlegroups.com> wrote:
>
> Here's the thing, though: we are actually thinking about removing the
> MessageLite::GetTypeName method at some point in the future. Lite protos
> are intended primarily for mobile and so in that environment it's important
> to keep the binary as small as possible and also avoid including symbols in
> the code that's distributed, whereas currently that method requires us to
> generate code that includes the message type names. So I think it would be
> best to avoid creating another dependency on that GetTypeName() method when
> it might be going away in the future.
>
>
> This seems to suggest that you don’t intend to support Any for mobile?
>
> Tim
>
>

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


Re: [protobuf] protobuf::Any Message vs MessageLite interface

2016-10-07 Thread Tim Kientzle

> On Oct 7, 2016, at 9:54 AM, 'Adam Cozzette' via Protocol Buffers 
>  wrote:
> 
> Here's the thing, though: we are actually thinking about removing the 
> MessageLite::GetTypeName method at some point in the future. Lite protos are 
> intended primarily for mobile and so in that environment it's important to 
> keep the binary as small as possible and also avoid including symbols in the 
> code that's distributed, whereas currently that method requires us to 
> generate code that includes the message type names. So I think it would be 
> best to avoid creating another dependency on that GetTypeName() method when 
> it might be going away in the future.
> 

This seems to suggest that you don’t intend to support Any for mobile?

Tim

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.