Lots of C++ compiler warnings

1,362 views
Skip to first unread message

Zachary Turner

unread,
Aug 13, 2008, 12:10:01 PM8/13/08
to Protocol Buffers
When I include my generated code in my C++ project in Visual Studio, I
get TONS of warnings. Here are a few of them

1>test.pb.cc
1>c:\dev\common_inc\google\protobuf\unknown_field_set.h(188) : warning
C4251: 'google::protobuf::UnknownField::varint_' : class
'google::protobuf::RepeatedField<Element>' needs to have dll-interface
to be used by clients of class 'google::protobuf::UnknownField'
1> with
1> [
1> Element=google::protobuf::uint64
1> ]


1>c:\test\shared\src\test.pb.cc(168) : warning C4355: 'this' : used in
base member initializer list

And lots of data conversion warnings. Are there any plans to address
these soon?

Kenton Varda

unread,
Aug 13, 2008, 12:41:37 PM8/13/08
to Zachary Turner, Protocol Buffers
Please read vsprojects/readme.txt for information about these.

Zachary Turner

unread,
Aug 13, 2008, 12:52:25 PM8/13/08
to Kenton Varda, Protocol Buffers
Fair enough, but many of these warnings are trivially easy to fix in the generated code so that I don't have to do global disabling of warnings for my entire project, or dirty up the code with pragmas wrapping individual includes to protocol buffer headers.  In most cases, you can just insert a cast into the generated code. 
 
The only ones that are not trivial to fix are the template dll-interface warning, the "this used in member initializer list" warning, and the function deprecated warning.  Even the function deprecation warning though should be easy to fix, since there is usually an equivalent non deprecated version.  I'd hate to think I have to globally disable warnings across my entire project, and many companies have "code quality" standards in place governing warnings, some of which go so far as to physically prevent you from checking code into the source control if certain warnings exist. 

Kenton Varda

unread,
Aug 13, 2008, 2:01:51 PM8/13/08
to Zachary Turner, Protocol Buffers
On Wed, Aug 13, 2008 at 9:52 AM, Zachary Turner <diviso...@gmail.com> wrote:
Fair enough, but many of these warnings are trivially easy to fix in the generated code so that I don't have to do global disabling of warnings for my entire project, or dirty up the code with pragmas wrapping individual includes to protocol buffer headers.  In most cases, you can just insert a cast into the generated code. 

Feel free to submit a patch which fixes the warnings in cases where they are easy to fix.
 
 The only ones that are not trivial to fix are the template dll-interface warning, the "this used in member initializer list" warning, and the function deprecated warning.  Even the function deprecation warning though should be easy to fix, since there is usually an equivalent non deprecated version.

In most cases the "non-deprecated" version is Win32-specific.  I would prefer to avoid using different code paths on Windows as much as possible as they would be hard to maintain.
 
  I'd hate to think I have to globally disable warnings across my entire project, and many companies have "code quality" standards in place governing warnings, some of which go so far as to physically prevent you from checking code into the source control if certain warnings exist.  

Yes, we do that too.  In particular, we use -Werror with GCC so that all warnings are treated as errors.  Unfortunately, MSVC issues warnings in a lot of cases where there is simply no problem present, and as we do most development using GCC it's really hard to keep the MSVC build warning-free.
Reply all
Reply to author
Forward
0 new messages