[Coin-discuss] Compiling Osi with gcc 2.95.3

Lou Hafer lou at cs.sfu.ca
Mon Feb 21 21:21:22 EST 2005


Folks,

	C++ nitpicking follows, some of you may want to tune out.

	The question from Ted Ralphs was ``Why did the `using' declarations
get into OsiColCut.hpp?'' I responded (waving hands furiously) ``Used to
suppress some overload warning from Forte C++.'' Mike Hennebry replied ``A
name in a derived class should hide the same name in the base class.''
Implied, from his example, was ``Unless you have a `using' declaration.''

	So, here's the example I promised. The declarations are:

OsiCut.hpp:	inline virtual bool operator==(const OsiCut& rhs) const; 
OsiColCut.hpp:	inline virtual bool operator==(const OsiColCut& rhs) const; 
	
	Warnings from Forte, without the `using' declarations:

Compiling OsiColCut.cpp
"include/OsiColCut.hpp", line 148: Warning: OsiColCut::operator== hides the
virtual function OsiCut::operator==(const OsiCut&) const.
"include/OsiColCut.hpp", line 148: Warning: OsiColCut::operator!= hides the
virtual function OsiCut::operator!=(const OsiCut&) const.
2 Warning(s) detected.

No warnings if the `using' declarations are in place.

	Mike's example is correct in principle. Forte C++ differs on the
mixed cases. Possibly because it's not possible to construct a bare OsiCut
object (protected constructor). The best that can be done is point at an
OsiColCut with an OsiCut pointer or reference. I crafted an example which
exploits extra tests in the derived OsiColCut::operator==, and got the
following result:

base == base		uses OsiCut::operator==
base == derived		uses OsiCut::operator==
derived == base		uses OsiCut::operator== ; compile error without `using'
derived == derived	uses OsiColCut::operator==

Apparently Forte is unwilling to fall back to OsiCut::operator== unless the
`using' declaration is in place, and thus warns about it.

	Forte generates similar warnings in many other parts of COIN.

	The visible tradeoff is gcc 2.95 compatibility vs. a reduction in
Forte warning messages and some extra flexibility that is most likely unused.

						Lou




More information about the Coin-discuss mailing list