earthwormgaz <earthworm...@googlemail.com> wrote in news:92671b7a-49f2-
4994-8dcf-82f1e61ef...@j9g2000vbp.googlegroups.com:
I'm trying to compile Log4cpp on Solaris with Suncc. In it, you've
got ...
class Catagory {
public:
virtual bool ownsAppender(Appender* appender) const throw();
private:
virtual bool ownsAppender(Appender* appender,
OwnsAppenderMap::iterator& i2) throw();
};
class LOG4CPP_EXPORT FixedContextCategory : public Category {
public:
virtual bool ownsAppender(Appender* appender) const throw();
};
With that, Suncc complains that ...
Compiling Libs/log4cpp/FixedContextCategory.cpp
"./Libs/log4cpp/log4cpp/FixedContextCategory.hh", line 171: Warning:
log4cpp::FixedContextCategory::ownsAppender hides the virtual function
log4cpp::Category::ownsAppender(log4cpp::Appender*,
__rwstd::__rb_tree<log4cpp::Appender*,
std::pair<log4cpp::Appender*const, bool>,
__rwstd::__select1st<std::pair<log4cpp::Appender*const, bool>,
log4cpp::Appender*>, std::less<log4cpp::Appender*>,
std::allocator<std::pair<log4cpp::Appender*const, bool>>>::iterator&).
[snip inadequate solution]
What can I do to get rid of the warning and
the error?
The developer of the library could change the name of one of the
overloads. In case of virtual functions one already has a lot of
complexity because of overrides, IMO it is not wise to add another
dimension of complexity via overloads, regardless of whether it produces
compiler warnings or not.
This change would require some care as the name must be changed in all
derived classes overriding this function. There is not much you can
reasonably do yourself - you can just ignore the warning or suppress it
by compiler switches.
hth
Paavo
That sums up my thinking on this to be honest. It seems pointless to
have used overloading in a confusing way like that. I'll see if I can