Re: [Boost-users] boost serialization excessive warning messages

From: gast128 (gast128_at_[hidden])
Date: 2007-08-14 15:01:34

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.