Virtual private and public overloaded method in sub classes

E

earthwormgaz

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::eek:wnsAppender hides the virtual function
log4cpp::Category::eek:wnsAppender(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&).

I thought I had the solution in adding this to the sub class ...

using Category::eek:wnsAppender; // add base-class functions to
overload set

That led to an error about the private overload in the base class
being inaccessible though. What can I do to get rid of the warning and
the error?

Many thanks,

Gaz
 
E

earthwormgaz

It's always recommended to post *real* code.  This apparently isn't.

Well, I tried to include as much real code as I could without it being
cluttered.
Ignore the warning (disable it if you can).  Remove the 'using' to get
rid of the error.

Okay, so SunCC is wrong then ...

Well, VC++ doesn't moan about this.
 
E

earthwormgaz

If you can't extract pieces of your *real* code without messing them up,

Sorry about that.
In what sense?  In which part?

In issuing the warning.

class Appender;

class Catagory {
public:
virtual bool ownsAppender(Appender* appender);
private:
virtual bool ownsAppender(Appender* appender, int & i2) throw();

};

class FixedContextCategory : public Category {
public:
virtual bool ownsAppender(Appender* appender);

};

SunCC will complain that

virtual bool Catagory::eek:wnsAppender(Appender* appender, int & i2)
throw();

.... is hidden by ...

virtual bool FixedContextCategory::eek:wnsAppender(Appender* appender);

Full text of the warning ...

Compiling Libs/log4cpp/FixedContextCategory.cpp
"./Libs/log4cpp/log4cpp/FixedContextCategory.hh", line 171: Warning:
log4cpp::FixedContextCategory::eek:wnsAppender hides the virtual function
log4cpp::Category::eek:wnsAppender(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&).
1 Warning(s) detected.

Thanks for replying, and dealing with my broken example.
 
P

Paul Bibbings

earthwormgaz said:
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::eek:wnsAppender hides the virtual function
log4cpp::Category::eek:wnsAppender(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&).

So, if I understand you, this is a *warning* you receive in trying to
build a library that you have not written yourself.
I thought I had the solution in adding this to the sub class ...

Bearing in mind that this is a warning from a particular compiler on a
library that has presumably been written with portability in mind, what
exactly is it that you are attempting to `solve' here? What is the
/problem/?

Being a warning (as opposed to an error) it is information to you that
might or might not be relevant to the correctness of the
implementation. Before you try and solve anything, have you verified
that there is a relevance here? The question to ask yourself here (and
perhaps, even, to ask the library implementers) is "is it a problem, in
this context, if FixedContextCategory::eek:wnsAppender(...) hides
Category::eek:wnsAppender(...)?
using Category::eek:wnsAppender; // add base-class functions to
overload set

Again, you are attempting to solve a /problem/ without having first
identified it as such...
That led to an error about the private overload in the base class
being inaccessible though.

....and, in doing so, you broke it!
What can I do to get rid of the warning and
the error?

Why not initially accept the warning for what it is - information that
may or may not be relevant - then either test or inquire as to whether
there is, in fact, any problem that might arise from the hiding. At the
very least, take the code that you added back out. Until you can
understand the library code itself it would be unwise to try and /mend/
it, especially where you haven't first identified that it needs mending.

Your `meddling' looks, from here, a lot like an attempt to cure a
patient of a condition that they don't have with medicine that is making
them ill.

Regards

Paul Bibbings
 
V

Victor Bazarov

[in response to "SunCC is wrong"]
In what sense? In which part?

In issuing the warning.

No, it's not wrong. The compilers are free to issue any warnings they
want. There are some situations when they *must* issue a diagnostic, as
required by the Standard, but there is no requirement *not to* issue a
diagnostic.

FWIW, the compiler is free to issue a warning in the line of, "the
compilation of your code proceeded successfully". It's just a
diagnostic message, just like a doctor's telling you "you're healthy".
class Appender;

class Catagory {
public:
virtual bool ownsAppender(Appender* appender);
private:
virtual bool ownsAppender(Appender* appender, int& i2) throw();

};

class FixedContextCategory : public Category {
public:
virtual bool ownsAppender(Appender* appender);

};

SunCC will complain that

virtual bool Catagory::eek:wnsAppender(Appender* appender, int& i2)
throw();

... is hidden by ...

virtual bool FixedContextCategory::eek:wnsAppender(Appender* appender);

Full text of the warning ...

Compiling Libs/log4cpp/FixedContextCategory.cpp
"./Libs/log4cpp/log4cpp/FixedContextCategory.hh", line 171: Warning:
log4cpp::FixedContextCategory::eek:wnsAppender hides the virtual function
log4cpp::Category::eek:wnsAppender(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&).
1 Warning(s) detected.

SunCC doesn't *complain* per se. It is *warning* you. If you ever
think of trying to call the hidden function while in a scope that would
resolve to 'FixedContextCategory' member, you might have a problem. But
until you do, there is no problem, there is no error, the diagnostic is
totally voluntary (not required by the Standard) on SunCC's part.

V
 
P

Paul Bibbings

earthwormgaz said:
class Appender;

class Catagory {
public:
virtual bool ownsAppender(Appender* appender);
private:
virtual bool ownsAppender(Appender* appender, int & i2) throw();

};

class FixedContextCategory : public Category {
public:
virtual bool ownsAppender(Appender* appender);

};

SunCC will complain that

virtual bool Catagory::eek:wnsAppender(Appender* appender, int & i2)
throw();

... is hidden by ...

virtual bool FixedContextCategory::eek:wnsAppender(Appender* appender);

It will complain about more than that, given the above code. If you
look at your snippet closely you will note that FixedContextCategory
extends a base class that the compiler doesn't know anything about.

When posting code, use copy-and-paste so that you do not (as above)
introduce further errors incidental to the problem that you are
intending the group to consider.
Full text of the warning ...

Compiling Libs/log4cpp/FixedContextCategory.cpp
"./Libs/log4cpp/log4cpp/FixedContextCategory.hh", line 171: Warning:
log4cpp::FixedContextCategory::eek:wnsAppender hides the virtual function
log4cpp::Category::eek:wnsAppender(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&).
1 Warning(s) detected.

Thanks for replying, and dealing with my broken example.

In what sense is it *broken*? You are getting a warning about something
that may or may not be a problem? Have you identified that there is
actually any issue, in relation to the library code, from the hiding? I
do not know the lib and have not built and tested it. However, my best
guess would be that the implementers are aware of the hiding and of the
potential for some compilers to signal a warning about it.

Think of it like this. You're transporting lumber in the back of your
small car - how are you going to respond to the light on the dash
warning that your boot/trunk is open? Are you going to start randomly
sawing the lumber until you can get the boot/trunk shut, or are you
going to mutter under your breath "yeah, I /know/!"

Regards

Paul Bibbings
 
E

earthwormgaz

(e-mail address removed):








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::eek:wnsAppender hides the virtual function
log4cpp::Category::eek:wnsAppender(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
raise a bug against the package.

Thanks to everyone who replied.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top