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

From: gast128 (gast128_at_[hidden])
Date: 2007-08-14 17:35:49

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.