[boost] Re: Warnings about derivation without explicit access control specified

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-07-12 09:47:12

On Sat, 12 Jul 2003 12:32:11 +0200, Jens Maurer wrote:

> Daniel Frey wrote:
>> 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?

I think that it's not a good way to ask the user to provide certain
command-line flags. When we add 'private' to the code, the user is free
to enable or disable the warning. Otherwise, we would choose for him. I
prefer freedom for the user...

Another option would be a work-around in the code which disables the
warning locally. We have cases where this is used, but in the above
case, I don't think it's the easiest solution.

>> 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.

I wonder if it's possible to distinguish regressions into "fail" and "not
supported", where the latter means that it fails and we (currently?)
can't make it work. This way it might be easier to find regressions that
are supposed to work but fail because of "accidents" :)

Regards, Daniel