Re: warnings compiling generated code on Snow Leopard
I'm OK with a patch that just adds the call to Message(). I'm not OK with a patch that explicitly initializes every single field, which is what Michael is talking about, since it conflicts with an optimization we did to reduce code size. I'd also rather not add an option for this because it would be tedious to maintain and test and we have too many options already. On Mon, Aug 31, 2009 at 5:17 PM, Michael Poole wrote: > > Joshua Haberman writes: > > > The protobuf library compiled and installed fine, but the generated > > classes threw warnings (and since I was compiling with -Werror, failed > > to compile). The warning was: > > > > benchmarks/google_messages.pb.cc: In copy constructor > > ‘benchmarks::SpeedMessage2::SpeedMessage2(const > > benchmarks::SpeedMessage2&)’: > > benchmarks/google_messages.pb.cc:4179: warning: base class ‘class > > google::protobuf::Message’ should be explicitly initialized in the > > copy constructor > > > > I thought this was an odd warning, since the constructors don't > > explicitly initialize their base classes, and do not throw warnings. > > I also thought it was odd since other versions of gcc don't throw this > > warning AFAIK. > > This warning is triggered by using g++'s -Weffc++ warning flag. I > raised this before[1], with a patch that was backed out because it led > to constructor code being duplicated. > > Making both sides happy probably involves adding a command-line flag > to protoc that toggles how it generates code: by default, omitting > those constructor calls, but allowing the user to ask for those > constructors to be called. > > Kenton, would that be a reasonable approach? If so, I should have > time to update my patch to do that and resubmit. > > [1] http://code.google.com/p/protobuf/issues/detail?id=86 > > Michael Poole > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. 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 -~--~~~~--~~--~--~---
Re: warnings compiling generated code on Snow Leopard
On Aug 31, 5:17 pm, Michael Poole wrote: > Joshua Haberman writes: > > The protobuf library compiled and installed fine, but the generated > > classes threw warnings (and since I was compiling with -Werror, failed > > to compile). The warning was: > > > benchmarks/google_messages.pb.cc: In copy constructor > > ‘benchmarks::SpeedMessage2::SpeedMessage2(const > > benchmarks::SpeedMessage2&)’: > > benchmarks/google_messages.pb.cc:4179: warning: base class ‘class > > google::protobuf::Message’ should be explicitly initialized in the > > copy constructor > > > I thought this was an odd warning, since the constructors don't > > explicitly initialize their base classes, and do not throw warnings. > > I also thought it was odd since other versions of gcc don't throw this > > warning AFAIK. > > This warning is triggered by using g++'s -Weffc++ warning flag. I > raised this before[1], with a patch that was backed out because it led > to constructor code being duplicated. > > Making both sides happy probably involves adding a command-line flag > to protoc that toggles how it generates code: by default, omitting > those constructor calls, but allowing the user to ask for those > constructors to be called. > > Kenton, would that be a reasonable approach? If so, I should have > time to update my patch to do that and resubmit. > > [1]http://code.google.com/p/protobuf/issues/detail?id=86 Hmm, this does not seem to be the same warning. The warning you cite is about a failure to initialize member variables. The warning I encountered is about a failure to explicitly call the constructor for the base class. I am guessing that addressing my warning would not cause any extra code to be emitted, because it's just making an implicit base class constructor explicit. Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. 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 -~--~~~~--~~--~--~---
Re: warnings compiling generated code on Snow Leopard
Joshua Haberman writes: > The protobuf library compiled and installed fine, but the generated > classes threw warnings (and since I was compiling with -Werror, failed > to compile). The warning was: > > benchmarks/google_messages.pb.cc: In copy constructor > ‘benchmarks::SpeedMessage2::SpeedMessage2(const > benchmarks::SpeedMessage2&)’: > benchmarks/google_messages.pb.cc:4179: warning: base class ‘class > google::protobuf::Message’ should be explicitly initialized in the > copy constructor > > I thought this was an odd warning, since the constructors don't > explicitly initialize their base classes, and do not throw warnings. > I also thought it was odd since other versions of gcc don't throw this > warning AFAIK. This warning is triggered by using g++'s -Weffc++ warning flag. I raised this before[1], with a patch that was backed out because it led to constructor code being duplicated. Making both sides happy probably involves adding a command-line flag to protoc that toggles how it generates code: by default, omitting those constructor calls, but allowing the user to ask for those constructors to be called. Kenton, would that be a reasonable approach? If so, I should have time to update my patch to do that and resubmit. [1] http://code.google.com/p/protobuf/issues/detail?id=86 Michael Poole --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. 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 -~--~~~~--~~--~--~---
Re: warnings compiling generated code on Snow Leopard
Good point, this was with -Wextra (which I had forgotten I compile
with). I can understand if you're not interested in accommodating
this. It is strange that -Wextra warns about this for this particular
gcc version, but not others that I've tried.
On Aug 31, 4:49 pm, Kenton Varda wrote:
> What compiler flags are you using? Since you were able to compile
> libprotobuf itself, I assume you have turned on additional warnings for your
> own project?
>
> On Mon, Aug 31, 2009 at 3:26 PM, Joshua Haberman wrote:
>
>
>
>
>
> > I just installed Snow Leopard, which ships with:
>
> > $ gcc --version
> > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
> > Copyright (C) 2007 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There
> > is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
>
> > The protobuf library compiled and installed fine, but the generated
> > classes threw warnings (and since I was compiling with -Werror, failed
> > to compile). The warning was:
>
> > benchmarks/google_messages.pb.cc: In copy constructor
> > ‘benchmarks::SpeedMessage2::SpeedMessage2(const
> > benchmarks::SpeedMessage2&)’:
> > benchmarks/google_messages.pb.cc:4179: warning: base class ‘class
> > google::protobuf::Message’ should be explicitly initialized in the
> > copy constructor
>
> > I thought this was an odd warning, since the constructors don't
> > explicitly initialize their base classes, and do not throw warnings.
> > I also thought it was odd since other versions of gcc don't throw this
> > warning AFAIK.
>
> > When I changed the copy constructors to explicitly initialize the
> > parent class, the warnings went away, a la:
>
> > SpeedMessage2::SpeedMessage2(const SpeedMessage2& from)
> > : google::protobuf::Message() {
> > SharedCtor();
> > MergeFrom(from);
> > }
>
> > Would you accept a patch that emits the above code for copy
> > constructors?
>
> > Josh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
Re: warnings compiling generated code on Snow Leopard
What compiler flags are you using? Since you were able to compile
libprotobuf itself, I assume you have turned on additional warnings for your
own project?
On Mon, Aug 31, 2009 at 3:26 PM, Joshua Haberman wrote:
>
> I just installed Snow Leopard, which ships with:
>
> $ gcc --version
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> The protobuf library compiled and installed fine, but the generated
> classes threw warnings (and since I was compiling with -Werror, failed
> to compile). The warning was:
>
> benchmarks/google_messages.pb.cc: In copy constructor
> ‘benchmarks::SpeedMessage2::SpeedMessage2(const
> benchmarks::SpeedMessage2&)’:
> benchmarks/google_messages.pb.cc:4179: warning: base class ‘class
> google::protobuf::Message’ should be explicitly initialized in the
> copy constructor
>
> I thought this was an odd warning, since the constructors don't
> explicitly initialize their base classes, and do not throw warnings.
> I also thought it was odd since other versions of gcc don't throw this
> warning AFAIK.
>
> When I changed the copy constructors to explicitly initialize the
> parent class, the warnings went away, a la:
>
> SpeedMessage2::SpeedMessage2(const SpeedMessage2& from)
>: google::protobuf::Message() {
> SharedCtor();
> MergeFrom(from);
> }
>
> Would you accept a patch that emits the above code for copy
> constructors?
>
> Josh
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
warnings compiling generated code on Snow Leopard
I just installed Snow Leopard, which ships with:
$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
The protobuf library compiled and installed fine, but the generated
classes threw warnings (and since I was compiling with -Werror, failed
to compile). The warning was:
benchmarks/google_messages.pb.cc: In copy constructor
‘benchmarks::SpeedMessage2::SpeedMessage2(const
benchmarks::SpeedMessage2&)’:
benchmarks/google_messages.pb.cc:4179: warning: base class ‘class
google::protobuf::Message’ should be explicitly initialized in the
copy constructor
I thought this was an odd warning, since the constructors don't
explicitly initialize their base classes, and do not throw warnings.
I also thought it was odd since other versions of gcc don't throw this
warning AFAIK.
When I changed the copy constructors to explicitly initialize the
parent class, the warnings went away, a la:
SpeedMessage2::SpeedMessage2(const SpeedMessage2& from)
: google::protobuf::Message() {
SharedCtor();
MergeFrom(from);
}
Would you accept a patch that emits the above code for copy
constructors?
Josh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
Re: Example produces error.
Thanks for fixing the docs, Henner.
On Sat, Aug 29, 2009 at 6:59 PM, Henner Zeller wrote:
> And yeah, documentation needs to be fixed.
>
> On Aug 28, 2009 1:35 PM, "Omnifarious" wrote:
>
>
> An example from
> http://code.google.com/apis/protocolbuffers/docs/proto.html
> produces an error when fed into protoc:
>
> $ protoc example.proto --cpp_out=.
> example.proto:8:20: Expected "{".
> example.proto:15:1: Reached end of input in message definition
> (missing '}').
> $ cat example.proto
> message Outer { // Level 0
> message MiddleAA { // Level 1
>message Inner { // Level 2
> required int64 ival = 1;
> optional bool booly = 2;
>}
> }
> message MiddleBB = { // Level 1
>message Inner = { // Level 2
> required int32 ival = 1;
> optional bool booly = 2;
>}
> }
> }
>
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
Re: trouble with NewCallback (C++)
That makes perfect sense---thanks.
On Mon, Aug 31, 2009 at 12:36 PM, Kenton Varda wrote:
> The problem is that the parameter binding that you are providing has type
> DummyResponse* but the method you are trying to bind takes const
> DummyResponse*. Even though the former is implicitly convertible to the
> latter, the compiler will not consider this when selecting a template
> overload. The solution is to manually cast the pointer to make it const
> before calling NewCallback.
>
> On Sun, Aug 30, 2009 at 9:29 PM, srlindemann wrote:
>
>>
>> I've been messing with the Service interface in C++ but have hit a few
>> bumps with the NewCallback method. Basically, the compiler (g++ 4.2.4
>> on Ubuntu) seems to be unable to match my function call to one of the
>> template overloads---it then fails when it tries to match it to the
>> void(*)() signature. Is there something here I'm missing? I'm using
>> protobuf-2.2.0.
>>
>> Source (closure_trouble.cpp):
>>
>> #include
>>
>> class DummyResponse
>> {
>> };
>>
>> class ClosureTest
>> {
>> public:
>>void MethodWithArg(const DummyResponse* response) {}
>> };
>>
>> int main(int argc, char* argv[])
>> {
>>ClosureTest ct;
>>DummyResponse dr;
>>
>>google::protobuf::Closure* closure = google::protobuf::NewCallback
>> (&ct, &ClosureTest::MethodWithArg, &dr);
>>return 0;
>> }
>>
>> Command line:
>> m...@my-laptop:~/Programming/cpp/protio/protio_main/tests$ g++ -o
>> closure_trouble closure_trouble.cpp
>> closure_trouble.cpp: In function ‘int main(int, char**)’:
>> closure_trouble.cpp:18: error: cannot convert ‘ClosureTest*’ to ‘void
>> (*)()’ for argument ‘1’ to ‘google::protobuf::Closure*
>> google::protobuf::NewCallback(void (*)())’
>>
>> Any thoughts? Thanks.
>>
>> (P.S. I tried a number of similar variations, such as a function
>> instead of a instance method, etc. Couldn't make anything work except
>> subclassing Closure.)
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
Re: proto with java & c++ & python
C++ Protocol Buffers use UTF-8 for all text encoding, regardless of platform. If you want to use some other encoding in your code, you will have to manually convert between that and UTF-8 when interacting with Protocol Buffers. In Java and Python everything is taken care of automatically, since these languages have built-in unicode support. In Java, protocol buffers uses String object (which are unicode) to represent strings, and in Python you can use the "unicode" builtin type for unicode. On Sun, Aug 30, 2009 at 8:00 PM, IChina wrote: > > Hi All: > > I want to use PB to RPC, in java c++ python. > > They have interact. > > In windows, vs2008 unicode mode is use UTF16, but in linux is UTF8. > > I don't know this is ok?encode support is ok? > > Generally, python is used UTF8 , also. > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. 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 -~--~~~~--~~--~--~---
Re: trouble with NewCallback (C++)
The problem is that the parameter binding that you are providing has type
DummyResponse* but the method you are trying to bind takes const
DummyResponse*. Even though the former is implicitly convertible to the
latter, the compiler will not consider this when selecting a template
overload. The solution is to manually cast the pointer to make it const
before calling NewCallback.
On Sun, Aug 30, 2009 at 9:29 PM, srlindemann wrote:
>
> I've been messing with the Service interface in C++ but have hit a few
> bumps with the NewCallback method. Basically, the compiler (g++ 4.2.4
> on Ubuntu) seems to be unable to match my function call to one of the
> template overloads---it then fails when it tries to match it to the
> void(*)() signature. Is there something here I'm missing? I'm using
> protobuf-2.2.0.
>
> Source (closure_trouble.cpp):
>
> #include
>
> class DummyResponse
> {
> };
>
> class ClosureTest
> {
> public:
>void MethodWithArg(const DummyResponse* response) {}
> };
>
> int main(int argc, char* argv[])
> {
>ClosureTest ct;
>DummyResponse dr;
>
>google::protobuf::Closure* closure = google::protobuf::NewCallback
> (&ct, &ClosureTest::MethodWithArg, &dr);
>return 0;
> }
>
> Command line:
> m...@my-laptop:~/Programming/cpp/protio/protio_main/tests$ g++ -o
> closure_trouble closure_trouble.cpp
> closure_trouble.cpp: In function ‘int main(int, char**)’:
> closure_trouble.cpp:18: error: cannot convert ‘ClosureTest*’ to ‘void
> (*)()’ for argument ‘1’ to ‘google::protobuf::Closure*
> google::protobuf::NewCallback(void (*)())’
>
> Any thoughts? Thanks.
>
> (P.S. I tried a number of similar variations, such as a function
> instead of a instance method, etc. Couldn't make anything work except
> subclassing Closure.)
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
Re: trouble with NewCallback (C++)
I was messing around in Visual Studio and tried this modification:
google::protobuf::Closure* closure =
google::protobuf::NewCallback(&ct,
&ClosureTest::MethodWithArg, &dr);
and it worked. Is explicitly specifying the template parameters the
preferred solution?
On Aug 30, 11:29 pm, srlindemann wrote:
> I've been messing with the Service interface in C++ but have hit a few
> bumps with the NewCallback method. Basically, the compiler (g++ 4.2.4
> on Ubuntu) seems to be unable to match my function call to one of the
> template overloads---it then fails when it tries to match it to the
> void(*)() signature. Is there something here I'm missing? I'm using
> protobuf-2.2.0.
>
> Source (closure_trouble.cpp):
>
> #include
>
> class DummyResponse
> {
>
> };
>
> class ClosureTest
> {
> public:
> void MethodWithArg(const DummyResponse* response) {}
>
> };
>
> int main(int argc, char* argv[])
> {
> ClosureTest ct;
> DummyResponse dr;
>
> google::protobuf::Closure* closure = google::protobuf::NewCallback
> (&ct, &ClosureTest::MethodWithArg, &dr);
> return 0;
>
> }
>
> Command line:
> m...@my-laptop:~/Programming/cpp/protio/protio_main/tests$ g++ -o
> closure_trouble closure_trouble.cpp
> closure_trouble.cpp: In function ‘int main(int, char**)’:
> closure_trouble.cpp:18: error: cannot convert ‘ClosureTest*’ to ‘void
> (*)()’ for argument ‘1’ to ‘google::protobuf::Closure*
> google::protobuf::NewCallback(void (*)())’
>
> Any thoughts? Thanks.
>
> (P.S. I tried a number of similar variations, such as a function
> instead of a instance method, etc. Couldn't make anything work except
> subclassing Closure.)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
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
-~--~~~~--~~--~--~---
