Re: Serialization of unset fields

2009-02-25 Thread Leon Mergen
Hello Kenton, Thanks for your reply. I actually read that text earlier, but didn't get what you're saying from that text (still don't), probably because it's kind of abstract. My guess is that you're talking about this: If any of your elements are optional, the encoded message may or may not

protobuf cleanup (aka memory leaks)

2009-02-25 Thread Ivan Kharin
Hi all! I'm trying to use protobuf in my project (photoshop plug-in), and encountered a problem: my DLL module is loaded/unloaded by host (many times). source code generated by protoc contains many XXX_descriptor_, XXX_reflection_, XXX::default_instance_ pointers and no function for cleanup

Re: Isn't the choice of std::string (C++ API) as a container for binary serialized bytes dangerous b/c of null termination?

2009-02-25 Thread Kenton Varda
You may be right, but we've done it that way for many years, and it would be too hard to change now. Are there any known STL implementations that use simple null-terminated strings? string::size() would have to be O(n) for them, which would be unfortunate. On Wed, Feb 25, 2009 at 8:30 AM, marc

Re: protobuf cleanup (aka memory leaks)

2009-02-25 Thread Kenton Varda
Hi Ivan, I'm pretty torn by this, because there are some people who absolutely insist that globals should not be cleaned up at shutdown, because it could cause still-running background threads that are using those objects to crash. I've argued that those threads should be cleaned up before

Re: Isn't the choice of std::string (C++ API) as a container for binary serialized bytes dangerous b/c of null termination?

2009-02-25 Thread marc
On Feb 25, 2:41 pm, Kenton Varda ken...@google.com wrote: You may be right, but we've done it that way for many years, and it would be too hard to change now. Are there any known STL implementations that use simple null-terminated strings?  string::size() would have to be O(n) for them,

Re: Isn't the choice of std::string (C++ API) as a container for binary serialized bytes dangerous b/c of null termination?

2009-02-25 Thread Kenton Varda
Good to know, thanks. On Wed, Feb 25, 2009 at 2:41 PM, marc vaill...@cis.jhu.edu wrote: On Feb 25, 2:41 pm, Kenton Varda ken...@google.com wrote: You may be right, but we've done it that way for many years, and it would be too hard to change now. Are there any known STL

Re: Isn't the choice of std::string (C++ API) as a container for binary serialized bytes dangerous b/c of null termination?

2009-02-25 Thread Dave Bailey
Kenton, The generated code for a string field has setters for std::string and const char *, but do you think you could add a (const char *, int length) setter as well (like you have for bytes fields)? Right now in protobuf-perlxs, we have to construct a temporary std::string in order to set a

Re: Isn't the choice of std::string (C++ API) as a container for binary serialized bytes dangerous b/c of null termination?

2009-02-25 Thread Kenton Varda
Sure. Actually, someone made that change to the internal code just the other day, so it'll be in SVN soon. You can also do: message.mutable_foo()-assign(data, size); which is equivalent to: message.set_foo(string(data, size)) but avoids the temporary string. On Wed, Feb 25, 2009 at 4:53