function object inheritence

[Malay Haldar]

I have a function object, from which I derive another function object
in which I overwrite the operator(). But now the operator() in the
base class seems inaccessible. For example, the following code doesn't
compile. Any insights on how to make it work ?

class C{};
struct X
{
void operator()( C const & ){}
};

struct Y : public X
{
void operator()( float ){}
}foo;

int main()
{
C c;
foo(c);
}

 

[Ron Natalie]

Declaring a name in a derived class hides the same name in the base class
unless you specifically bring it forward.

 

[Tim]

Declaring a name in a derived class hides the same name in the base class
unless you specifically bring it forward.

Hmm, exusing me for butting in, but I'm interested in the same issue and
have a couple of questions:

1) What's the way to do this using a compiler without namespace support?

2) Is Y:perator()(float) really an overload of X:perator()(C const &);
the parameters are different?

Regards


Tim

 

[John Carson]

Hmm, exusing me for butting in

And me.

1) What's the way to do this using a compiler without namespace
support?

struct Y : public X
{
void operator()( float ){}
void operator()( C const & arg)
{
X:perator ()(arg);
}
}foo;

2) Is Y:perator()(float) really an overload of X:perator()(C
const &); the parameters are different?

You mean "really a redefinition". The fact that the parameters are different
is irrelevant. If the operator name is the same, then all operators of the
same name in the base class are hidden (the same is true of functions; if,
for example, you have foo(int) in the base class, then foo(char) in the
derived class will hide foo(int) in the base class).

 

[Rolf Magnus]

Hmm, exusing me for butting in, but I'm interested in the same issue
and have a couple of questions:

1) What's the way to do this using a compiler without namespace
support?

What does this have to do with namespaces?
Anyway, if your C++ compiler doesn't support the above, it is not
standard compliant and you would have to ask in a place where that
compiler is topical.

2) Is Y:perator()(float) really an overload of X:perator()(C const
&); the parameters are different?

No, it isn't. As Ron said, the operator in Y hides the one in X. As soon
as you write a function in a derived class that has the same name, but
different signature than a function in the base class, all the base
class functions with that name are hidden in the derived class. You
have to add a using declaration to unhide them, and make them in fact
overloads.

 

[Tim Clacy]

What does this have to do with namespaces?

What does the keyword 'using' have to do with anything except namespaces?

Anyway, if your C++ compiler doesn't support the above, it is not
standard compliant and you would have to ask in a place where that
compiler is topical.

Hold on chap; most of us have to work with what we're supplied with, not
some hypothetical C++ compiler that is 100% compliant to the latest
ill-conceived after-thought. In fact, I think you'll find that only a
fraction of all C++ developers will be using compilers that implement all of
the very latest bells and whistles. Much to my chagrin, I'm lumbered with a
compiler for an embedded platform that does not support namespaces nor does
it fully support all of the template-related functionality. However, I'm
certainly not alone; in fact I think you'll find I'm in the majority. Even
VC 7.0 and gcc fall short in some regards as far as I understand.

 

[Rolf Magnus]

What does the keyword 'using' have to do with anything except
namespaces?

See the above example. Namespaces are not involved, and still there is
the keyword 'using'.

Hold on chap; most of us have to work with what we're supplied with,
not some hypothetical C++ compiler that is 100% compliant to the
latest ill-conceived after-thought.

Right. And there are newsgroups, forums, irc channels or whatever that
deal with specific compilers and other programming tools, be it real
world ones or hypothetical ones. However, this newsgroup doesn't. It
deals with the C++ programming language as defined by the ISO. If your
compiler doesn't support the 'using' keyword, then it's a problem about
that specific compiler.

In fact, I think you'll find that
only a fraction of all C++ developers will be using compilers that
implement all of the very latest bells and whistles.
Right.

Much to my chagrin, I'm lumbered with a compiler for an embedded
platform that does not support namespaces nor does it fully support
all of the template-related functionality.

I know that there are such compilers out there, and I know that there
may be good reasons for them to not support those things, but again,
dealing with their limitations is specific to those compilers and not a
general problem of the C++ language. If a compiler has some work-around
for a specific limitation, it's a good idea to ask in a place where
this compiler is the topic.

However, I'm certainly not alone; in
fact I think you'll find I'm in the majority. Even VC 7.0 and gcc fall
short in some regards as far as I understand.

Sure. I never claimed they did. But if I want to know a work-around for
some specific non-conforming behavior of g++, I'd e.g. ask in
gnu.g++.help for it.

 

[Tim Clacy]

See the above example. Namespaces are not involved, and still there is
the keyword 'using'.

Hmm, since what flavour of C++ revision has 'using' been a keyword that can
be used outside the context of 'namespace'?

Right. And there are newsgroups, forums, irc channels or whatever that
deal with specific compilers and other programming tools, be it real
world ones or hypothetical ones. However, this newsgroup doesn't. It
deals with the C++ programming language as defined by the ISO. If your
compiler doesn't support the 'using' keyword, then it's a problem
about that specific compiler.


I know that there are such compilers out there, and I know that there
may be good reasons for them to not support those things, but again,
dealing with their limitations is specific to those compilers and not
a general problem of the C++ language. If a compiler has some
work-around for a specific limitation, it's a good idea to ask in a
place where this compiler is the topic.


Sure. I never claimed they did. But if I want to know a work-around
for some specific non-conforming behavior of g++, I'd e.g. ask in
gnu.g++.help for it.

To clarify; if you have a real-world C++ question, ask in a
compiler-specific group, but if you have a totally abstract, language
related issue then this is the place?

 

[Rob Williscroft]

Tim Clacy wrote in

Tim Clacy wrote:

[snip]

See the above example. Namespaces are not involved, and still there
is the keyword 'using'.

Hmm, since what flavour of C++ revision has 'using' been a keyword
that can be used outside the context of 'namespace'?

Since using was introduced into the language.

[snip]

To clarify; if you have a real-world C++ question, ask in a
compiler-specific group, but if you have a totally abstract, language
related issue then this is the place?

There is *nothing* abstract about the C++ Standard. It provides a
way of writing portable C++, all those people that have put thousands
of man hour's into writing it didn't do just for fun.

There are only 2 way's of writing correct C++, Standard compliant C++,
the topic of this newsgroup and implementation specific, the topic
of you compiler implementors newsgroup. There is no middle ground here,
there is just *nothing* defined about "c++" compilers that don't
conform to the standard except what there vendor/implementors say.

BTW John Carson has given you a standard compliant answer to your
original query:

struct Y : public X
{
void operator()( float> ){}
void operator()( C const > & arg)
{
X:perator > ()(arg)> ;
}
}foo;

The only othere answer you can get to your question is "ask your
implementor".

You got both (valid) responses to your query, not a bad result.

Rob.

 

[Tim Clacy]

Tim Clacy wrote in

Tim Clacy wrote:

[snip]

What does the keyword 'using' have to do with anything except
namespaces?

See the above example. Namespaces are not involved, and still there
is the keyword 'using'.

Hmm, since what flavour of C++ revision has 'using' been a keyword
that can be used outside the context of 'namespace'?

Since using was introduced into the language.

[snip]

To clarify; if you have a real-world C++ question, ask in a
compiler-specific group, but if you have a totally abstract, language
related issue then this is the place?

There is *nothing* abstract about the C++ Standard. It provides a
way of writing portable C++, all those people that have put thousands
of man hour's into writing it didn't do just for fun.

There are only 2 way's of writing correct C++, Standard compliant C++,
the topic of this newsgroup and implementation specific, the topic
of you compiler implementors newsgroup. There is no middle ground
here, there is just *nothing* defined about "c++" compilers that don't
conform to the standard except what there vendor/implementors say.

BTW John Carson has given you a standard compliant answer to your
original query:

And thank you very much indeed to John Carson.

However, having moved on since then, my issue now is that according to some
folk, Mr. Carson shouldn't have even suggested a workaround since this was a
real-world question, not abstract.

 

[Rolf Magnus]

Hmm, since what flavour of C++ revision has 'using' been a keyword
that can be used outside the context of 'namespace'?

Well, it has been defined that way in standard C++ since there is a C++
standard (i.e. for about 5 years or so now). I don't know how long
before standardization the compilers have been doing this.

To clarify; if you have a real-world C++ question, ask in a
compiler-specific group, but if you have a totally abstract, language
related issue then this is the place?

They don't need to be "totally abstract", but they need to be compiler
independant. Even though there is probably no compiler that is 100%
standard compliant, most of the code shown here will still work on the
majority of them. After all, it's not like standard C++ is just
something abstract and C++ compiler dialects have nothing to do at all
with it.
If you find some unexpected behavior in a program and want to know if
that behavior is standard compliant or not, it's also fine to ask here
if you are correct or your compiler is.
But if you want to know why the compiler does it different or if it
provides some specific extension to the standard, or how to use the
compiler itself, that would better go to a forum dedicated to that
compiler.