Boost logo

Boost Users :

From: Jens Seidel (jensseidel_at_[hidden])
Date: 2007-08-14 17:07:41


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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net