Daniel Frey wrote:
> I saw a lot of new regression runs on various platforms.
Some of those are mine (HP-UX, IRIX, Solaris).
> One obvious
> question: Should we remove the outdated runs?
First, my setup is not completely cronjob-automated, so my runs
may become outdated. Second, my runs use different compilers
or different compiler versions than the tests already there.
> Now for the real reason of this message: One compiler (the SGI MIPSpro)
> complains (with a warning) about:
>
> cc-1234 CC: WARNING File = /net/cci/maurer/boost/libs/utility/operators_test.cpp,
> Line = 52
> Access control is not specified ("private" by default).
>
> : boost::operators<Wrapped1<T> >
>
> The question is: Should we, for the sake of portability, support this
> warning by requesting an explicit access control specifier whenever we
> derive?
Since only some Unix compilers give a warning there, and we may be able
to turn off the warning by command-line flags, people shouldn't probably
be made to change their habits. For me, it's obvious that private
derivation is the default here.
Do we want to add the command-line flag to turn off the warning?
> PS: Would it make sense to have a "boost bug bashing week" or something
> to fix some more bugs/regressions? Or do we wait for users to complain
> and provide fixes?
The libraries itself are relatively bug-free, but there are plenty of
portability problems with some compilers. For the HP-UX, IRIX, and DEC
compilers in the versions I have access to, it's probably a waste of time
to try and fix problems, unless it's obvious what to do, because the
compilers have relatively old front-ends with plenty of non-conformance
issues.
Jens Maurer
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
