Jens Seidel
On Tue, Aug 14, 2007 at 07:01:34PM +0000, gast128 wrote:
Jens Seidel
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.