boost serialization excessive warning messages
Hi Group, I am getting multiple warning messages like the following from boost serialization library: /usr/include/boost/archive/detail/iserializer.hpp:124: warning: unused parameter 'flags' I am pretty sure this is a common issue but I haven't found any clue through the web. Is there a way to turn off the warning through proper coding? I am using gcc on linux. Fei
Fei Liu <fei.liu <at> aepnetworks.com> writes:
Hi Group, I am getting multiple warning messages like the following from boost serialization library: /usr/include/boost/archive/detail/iserializer.hpp:124: warning: unused parameter 'flags'
I am pretty sure this is a common issue but I haven't found any clue through the web. Is there a way to turn off the warning through proper coding? I am using gcc on linux.
We are not using gcc here, but with Visual Studio one can supress these warnings like (example of using text archives): #pragma warning(push) #pragma warning(disable: 4100) //c4100: unreferenced formal parameter #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #pragma warning(pop) Probably gcc has similar features.
On Mon, Aug 13, 2007 at 09:16:20AM +0000, gast128 wrote:
Fei Liu <fei.liu <at> aepnetworks.com> writes:
I am getting multiple warning messages like the following from boost serialization library: /usr/include/boost/archive/detail/iserializer.hpp:124: warning: unused parameter 'flags'
I am pretty sure this is a common issue but I haven't found any clue through the web. Is there a way to turn off the warning through proper coding? I am using gcc on linux.
The simplest way is to fix the code! These warning are not useless, you will profit from it a lot. I assume you talk about unused variable arguments such as int test(int var) { return 1; } This code would using -Wall -Wextra (this warning level should be used as default, it is really good) complain about an unused "var". I suggest to check the code, maybe it's wrong. If all is right, you can replace it to int test(int /*var*/) { return 1; }
We are not using gcc here, but with Visual Studio one can supress these warnings like (example of using text archives):
I'm confused! You prefer to work with a proprietary program instead of a completly free one which even is much more standard conform has much more features (I can simple create a cross compiler, ...)? I'm really confused ...
#pragma warning(push) #pragma warning(disable: 4100)
I strongly suggest not to use any pragmas as this is compiler specific. Changing code would have affect on each compiler. There is only one pragma I ever used in my life, only one: #pragma omp for OpenMp parallelisation in GCC 4.2+. Jens
Jens Seidel <jensseidel <at> users.sf.net> writes:
On Mon, Aug 13, 2007 at 09:16:20AM +0000, gast128 wrote:
Fei Liu <fei.liu <at> aepnetworks.com> writes:
I am getting multiple warning messages like the following from boost serialization library: /usr/include/boost/archive/detail/iserializer.hpp:124: warning: unused parameter 'flags'
I am pretty sure this is a common issue but I haven't found any clue through the web. Is there a way to turn off the warning through proper coding? I am using gcc on linux.
The simplest way is to fix the code! These warning are not useless, you will profit from it a lot.
The answer I gave is to work around library issues: adapting source files from libraries is imo a bad idea. Lowering the warning level isn't either good. So with these pragma's one can temporary disable the level for that header.
We are not using gcc here, but with Visual Studio one can supress these warnings like (example of using text archives):
I'm confused! You prefer to work with a proprietary program instead of a completly free one which even is much more standard conform has much more features (I can simple create a cross compiler, ...)? I'm really confused ...
Say Mr. Seidel you probably don't work professionally in this business. Visual Studio 2003 is a nice ide a reasonable conforming compiler despite it comes from Redmond. And yes we could work with gcc, eclipse, bjam, emacs, gdb and a tons of other free tools, but for now Visual Studio works fine, since our company produces only for the Windows platform. And take a deep breath, because... we even use MFC...
I strongly suggest not to use any pragmas as this is compiler specific. Changing code would have affect on each compiler. There is only one pragma I ever used in my life, only one: #pragma omp for OpenMp parallelisation in GCC 4.2+.
Well take a look at Boost code as they use it themselves. To make it portable, guard them with compiler specific macro's. And yes it is better to fix the original code, but most of the times this is not an option. Freeing Boost from all unreferenced variables yourself, would take a week. And you can start over again when Boost 1.35 is launched.
gast128 wrote:
Well take a look at Boost code as they use it themselves. To make it portable, guard them with compiler specific macro's. And yes it is better to fix the original code, but most of the times this is not an option. Freeing Boost from all unreferenced variables yourself, would take a week. And you can start over again when Boost 1.35 is launched.
as far as the serialization library is concerned, a many/most of these will be addressed. Can't guarentee that all of them will as some compilers (e.g. gcc) generate warnings on things that have in fact been done intentionally. When that happens, I consider the warning and verify that it's not relevant and move on. That is I just accept that fact that the warning is legitimate, and overriding it with my own judgement is also legitimate. "Hiding" warnings sort of defeats the purpopse of warnings in the first place and tweaking code to avoid warning on all compilers is very compiler dependent - and most of already spend too much time on circular, pointless quests. Robert Ramey
Robert Ramey <ramey <at> rrsd.com> writes:
as far as the serialization library is concerned, a many/most of these will be addressed. Can't guarentee that all of them will as some compilers (e.g. gcc) generate warnings on things that have in fact been done intentionally. When that happens, I consider the warning and verify that it's not relevant and move on. That is I just accept that fact that the warning is legitimate, and overriding it with my own judgement is also legitimate. "Hiding" warnings sort of defeats the purpopse of warnings in the first place and tweaking code to avoid warning on all compilers is very compiler dependent - and most of already spend too much time on circular, pointless quests.
Serious warnings should be dealt with. At our company in the past however, one of the main products buided with 170 warnings. No way to detect the serious ones from the innocents. So then we introduced the 'warning as errors' policy and surpressed the really stupid ones. A developper now has to fix the warnings or code won't compile. Result 0 warnings. External header warnings are supressed by pragma's, which is good enough imo. I can give the example of the 'unused argument' warning, which indicates a potential forgotten argument or just a not needed argument. If it is the first option, the compiler found a bug; if it is the second case one can simply supress it by commenting it out (or use BOOST_UNREF macro) or maybe rearrange the prototype of the function. void f(int /*i*/) { //yes no warning }
gast128 wrote:
Robert Ramey <ramey <at> rrsd.com> writes: I can give the example of the 'unused argument' warning, which indicates a potential forgotten argument or just a not needed argument.
These are not in dispute - they will be addressed. Problem is your point of view assumes that one compiler in particular has no warnings which should be ignored in any particular case. This assumption is not true. So there cannot be a non-trivial program guarenteed to compile without warnings on all compilers. Even for a trivial program, the onlyway to verify it would be to test on all compilers. So there will always be at least some warnings. If you're going to make code for one particular compiler, then using pragma's around included headers should work well for you. Robert Ramey
Robert Ramey <ramey <at> rrsd.com> writes:
gast128 wrote:
Problem is your point of view assumes that one compiler in particular has no warnings which should be ignored in any particular case.
This assumption is not true.
Huh did I say that? I only said that if the library does not solve them, we have to work around them. It is not said that we disable every warning, but only the non harmful ones like: - unreferenced arguments - conditional expression is constant Leaves open the dangerous one (e.g. variables used without initialization) I hope those not to found in a library.
On Tue, Aug 14, 2007 at 07:01:34PM +0000, gast128 wrote:
Jens Seidel <jensseidel <at> users.sf.net> writes:
On Mon, Aug 13, 2007 at 09:16:20AM +0000, gast128 wrote: The simplest way is to fix the code! These warning are not useless, you will profit from it a lot.
The answer I gave is to work around library issues: adapting source files from libraries is imo a bad idea.
You're wrong. Especially as header files are included in all kind of user programs they need to be clean! This is the way Open Source works. One writes a really heavy and very useful software and not so experienced users correct what they think is wrong. So they stay in contact with upstream and start learning and will later maybe contribute own code. One person corrects not optimal code, hundreds or even thousands off users profit from it. Sounds good to me. It slows down my work as well to report each little error in each application (did it already three or four times today) but it is required! If you refer to Closed Source (which I do not know) it is still possible to tell the compiler that some include files are so called system headers and it will not report warnings in it (gcc option -isystem instead of -I to specify include paths). But again: Never use -isystem for Open Source code, report it instead!
Lowering the warning level isn't either good. So
Agreed!
with these pragma's one can temporary disable the level for that header.
Pragmas also make code very hard to read. And as I wrote already I didn't even know about pragmas until recently and never even tried to use code with is not portable. (Yes, I used libraries not yet ported to all systems, but it is at least possible to port the 3rd library stuff I used).
We are not using gcc here, but with Visual Studio one can supress these warnings like (example of using text archives):
I'm confused! You prefer to work with a proprietary program instead of a completly free one which even is much more standard conform has much more features (I can simple create a cross compiler, ...)? I'm really confused ...
Say Mr. Seidel you probably don't work professionally in this business. Visual
I do.
Studio 2003 is a nice ide a reasonable conforming compiler despite it comes
I know that it is commenly used (and probably most often without a valid license, but lets ignore this). But you probably know that one should always use (at least for tests) multiple compilers to improve the code and make it more portable. Isn't GCC the obvious solution? I know at least for sure that it is much easier to install as any proprietary program (just select it in the package manager, even in Windows, as there exists cygwin). I try often as many compilers as I have access to, it included also experimental ones ...
from Redmond. And yes we could work with gcc, eclipse, bjam, emacs, gdb and a tons of other free tools, but for now Visual Studio works fine, since our company produces only for the Windows platform.
I have to confess that I do not understand why some people create non-portable code ... There exist so many cross platform libraries.
And take a deep breath, because... we even use MFC...
Never heard of it, probably it's non free.
Well take a look at Boost code as they use it themselves. To make it portable, guard them with compiler specific macro's. And yes it is better to fix the original code, but most of the times this is not an option. Freeing Boost from
Why not? Maybe for you if you use non Open Source software but not for me.
all unreferenced variables yourself, would take a week. And you can start over again when Boost 1.35 is launched.
I don't understand why it isn't required to commit only clean code. Checking compiler errors and warnings is easily possible automatically (and I do so for my stuff). Jens
Jens Seidel <jensseidel <at> users.sf.net> writes:
On Tue, Aug 14, 2007 at 07:01:34PM +0000, gast128 wrote:
Jens Seidel <jensseidel <at> users.sf.net> writes:
On Mon, Aug 13, 2007 at 09:16:20AM +0000, gast128 wrote: The simplest way is to fix the code! These warning are not useless, you will profit from it a lot.
The answer I gave is to work around library issues: adapting source files
from
libraries is imo a bad idea.
You're wrong. Especially as header files are included in all kind of user programs they need to be clean! I agree that they should be clean, but if they are not what do you do? Waiting until they are clean? Adapt the headers yourself with previous mentioned drawbacks? Or just treat these headers as foreign and lower the level warning or disable warnings ONLY for those foreign headers.
This is the way Open Source works. One writes a really heavy and very useful software and not so experienced users correct what they think is wrong. So they stay in contact with upstream and start learning and will later maybe contribute own code. We use Boost as open source. But while it is looked and reviewed, it stil won't compile without warnings. So we disable these warnings for Boost headers. Luckily we didn't change the actual source because we 've used Boost since 2003 (1.29?)
One person corrects not optimal code, hundreds or even thousands off users profit from it. Sounds good to me. Ideal world, but maybe also an excercise in frustration. But feel glad to convince the Boost members that they should compile without warnings.
I try often as many compilers as I have access to, it included also experimental ones ...
I have to confess that I do not understand why some people create non-portable code ... There exist so many cross platform libraries.
Well to make things even worse I do create non portable code, and detect this only when we go from one Visual Studio version to the next one. We tried Visual Studio 2005, took me a week to get rid of most errors (e.g. they had removed the non confirming pow(int) overload). If I apply gcc it will cost me a month to get more confirming code without gaining direct commercial value. Employer will not pay that. And then I even not mention all the non confirming compilers. If you browse through all those Boost headers, one has to appreciate the work invested for all the (non trivial) work arounds. The code becomes quite unreadable, because of those macro's and #ifdef's, but then again there is no alternative except sending non confirming compiler builders to the galleys...
I don't understand why it isn't required to commit only clean code. Checking compiler errors and warnings is easily possible automatically (and I do so for my stuff). I think you should have this discussion with the moderators. I feel sympathetic, but I can also live with the pragma's.
On Tue, Aug 14, 2007 at 09:35:49PM +0000, gast128 wrote:
Jens Seidel <jensseidel <at> users.sf.net> writes:
On Tue, Aug 14, 2007 at 07:01:34PM +0000, gast128 wrote: Especially as header files are included in all kind of user programs they need to be clean!
I agree that they should be clean, but if they are not what do you do? Waiting
Report it (best with patch), such as in I did recently for SDL Pango: http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;dist=...
until they are clean?
It depends. If there are really errors in it I suggest to workaround if possible to be compatible (at least for some time). If it is not possible to workaround it change it locally and hope upstream will react soon.
Adapt the headers yourself with previous mentioned drawbacks? Or just treat these headers as foreign and lower the level warning or disable warnings ONLY for those foreign headers.
As long as only warning are affected I would do to obvious step: Switch to the development version (source code repository) where it should be already fixed if the project is still alive (as you sent the patch, do you remember :-) and otherwise just turn warnings off as you suggested. But if such warnings occur only rarely (because you do not change a special piece of your code often and don't need to recompile it) I would just ignore it (once it is reported of course).
This is the way Open Source
We use Boost as open source.
And I really think this is a very good idea :-) To be honest I only used Boost.test and Boost.Log (failed to became official yet). And at least for the second I indeed contacted the autor already. (And in Boost.test I did never find any errors except the current one which is the reason that I'm subscribed since short time.) It not good that I always complain so much. I will obtain Thursday the current Boost code and send patches (for -Wall and maybe later also -Wextra). Promised! Currently I have to fix a few errors in hex-a-hop, a funny game made free only a few days ago (try it out!).
I try often as many compilers as I have access to, it included also experimental ones ...
I have to confess that I do not understand why some people create non-portable code ... There exist so many cross platform libraries.
Well to make things even worse I do create non portable code, and detect this only when we go from one Visual Studio version to the next one. We tried Visual Studio 2005, took me a week to get rid of most errors (e.g. they had removed the non confirming pow(int) overload). If I apply gcc it will cost me a month to get more confirming code without gaining direct commercial value.
Exactly that's why I suggest you to test it with gcc as soon as possible. If you learn to avoid writing non portable code you will profit in the future, right? (But don't worry, I made many such errors as well, it's normal :-)) Again: it costs you nothing (except time). Look at least for major pitfalls.
Employer will not pay that.
I do such stuff often in my spare time. Since I work with/on Open Source it also makes a lot of fun!
And then I even not mention all the non confirming compilers.
Yep. I knew in the past many compiler shipped with Unix workstations which were not conforming. Since these compilers are often installed per default I support working around issues as long as it makes sense. But I do not understand people who install proprietary compilers on systems which do not ship a default one (I know only one such system) if they are non conforming (here we are again at the start of our discussion :-).
appreciate the work invested for all the (non trivial) work arounds. The code becomes quite unreadable, because of those macro's and #ifdef's, but then again there is no alternative except sending non confirming compiler builders to the galleys...
Right :-( Jens
gast128 wrote:
The answer I gave is to work around library issues: adapting source files from libraries is imo a bad idea. Lowering the warning level isn't either good. So with these pragma's one can temporary disable the level for that header.
Actually, patching isn't that bad if you are a bit intelligent on how you upgrade. Sohail
participants (5)
-
Fei Liu -
gast128 -
Jens Seidel -
Robert Ramey -
Sohail Somani