Question about overloading member function names

T

toadwarble

I hit on a question today which seemed to be incorrect to me in the
version of g++ I'm using (4.1.1)

I have the following

enum rectype_t {
// Stuff....
};

class recordclass {
// Stuff....
};

class base {
// Stuff.....
protected:
void add_record(const recordclass &);
};

class derived1 : public base {
// More stuff....
public:
void add_record(const rectype_t);
};

class derived2: public base {
// More stuff...
public:
void add_record(const rectype_t);
};

However when I define the "add_record" functions for derived1 and
derived2 thus:

void derived1::add_record(const rectype_t rt)
{
recordclass rec(rt);
// Fiddle with rec
add_record(rec);
}

It chokes on the "add_record" which was meant to be a call to the base
class version.

It's OK if I put base:add_record(rec) or if I change the name of the
base class function to "add_rec".

Am I wrong to think that is unambiguous overloading or is g++ wrong?

Thanks

John Collins
Xi Software Ltd
 
J

Jim Langston

toadwarble said:
I hit on a question today which seemed to be incorrect to me in the
version of g++ I'm using (4.1.1)

I have the following

enum rectype_t {
// Stuff....
};

class recordclass {
// Stuff....
};

class base {
// Stuff.....
protected:
void add_record(const recordclass &);
};

class derived1 : public base {
// More stuff....
public:
void add_record(const rectype_t);
};

class derived2: public base {
// More stuff...
public:
void add_record(const rectype_t);
};

However when I define the "add_record" functions for derived1 and
derived2 thus:

void derived1::add_record(const rectype_t rt)
{
recordclass rec(rt);
// Fiddle with rec
add_record(rec);
base::add_record(rec);

}

It chokes on the "add_record" which was meant to be a call to the base
class version.

It's OK if I put base:add_record(rec) or if I change the name of the
base class function to "add_rec".

Am I wrong to think that is unambiguous overloading or is g++ wrong?

Thanks

John Collins
Xi Software Ltd
 
T

toadwarble

Sorry yes I spotted that after I posted it but I hoped people would
get my drift.

Can anyone help with the question?

John Collins
Xi Software Ltd
 
A

Alf P. Steinbach

* toadwarble:
I hit on a question today which seemed to be incorrect to me in the
version of g++ I'm using (4.1.1)

I have the following

enum rectype_t {
// Stuff....
};

class recordclass {
// Stuff....
};

class base {
// Stuff.....
protected:
void add_record(const recordclass &);
};

class derived1 : public base {
// More stuff....
public:
void add_record(const rectype_t);
};

class derived2: public base {
// More stuff...
public:
void add_record(const rectype_t);
};

However when I define the "add_record" functions for derived1 and
derived2 thus:

void derived1::add_record(const rectype_t rt)
{
recordclass rec(rt);
// Fiddle with rec
add_record(rec);
}

It chokes on the "add_record" which was meant to be a call to the base
class version.

It's OK if I put base:add_record(rec) or if I change the name of the
base class function to "add_rec".

Am I wrong to think that is unambiguous overloading or is g++ wrong?

"add_record" in "derived1" hides the "add_record" in "base".

You can either qualify the call with class name,

base::add_record( rec );

which can alternatively be done via "derived1" wrapper,

void add_record( recordclass const& r ) { base::add_record( r ); }

or call via a "base" reference or pointer,

base& super = *this;
super.add_record (rec );

or bring the "base::add_record" overloads into "derived1" via a "using"
declaration

class derived1: public base
{
protected:
using base::add_record;
public:
void add_record( rectype_t const );
};

The FAQ item discussing this is found at <url:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9>.

It doesn't discuss the reason why the language is this way. It's simply
a more or less arbitrary choice of one evil instead of another. With
the current rules, an introduction or removal of an overload in the base
class won't affect which function is called in a derived class, except
when you use the "using" solution where you say OK, fine by me.


Cheers, & hth.,

- Alf
 
J

Jerry Coffin

I hit on a question today which seemed to be incorrect to me in the
version of g++ I'm using (4.1.1)

I have the following

[ ... derived class function hiding base class function ]
However when I define the "add_record" functions for derived1 and
derived2 thus:

void derived1::add_record(const rectype_t rt)
{
recordclass rec(rt);
// Fiddle with rec
add_record(rec);
}

It chokes on the "add_record" which was meant to be a call to the base
class version.

The rule in C++ is that it looks backward through the "stack" of
available scopes to find the name you've used. Once it finds a scope
with that name, it looks for any overloads of that name in that scope.
If one of them works, that's great. Otherwise, you have an error. Once
it has found a scope where that name is visible, however, it NEVER
attempts to search through more scopes to find more instances of the
same name.

Although it doesn't arise nearly as often in C, this rule is one that
was inherited from C. For example, if I had something like this:

double x;

void f() {
int x=1;

x = 2.1;
printf("%d\n", x);
}

Even though the type of the value being assigned is a double, and there
is a double named x at global scope, the assignment is to the x that's
local to f(), because as soon as the compiler finds that x, it quits
looking for more.

This is done so that each part of the program is as independent as
possible. Without it, a change elsewhere in the program could change
behavior of code that you think is fully tested and completely
independent. For example, assume that in the code above, f() was
originally written independently, and only later somebody added the
global x. When they do so, the behavior of f() suddenly changes -- if
the assignment is to the global, then there's no assignment to the
local, and the function prints out 1 instead of 2.

In C++ overloading allows us to have multiple "things" in the same scope
with the same name. The rest of the rule remains the same though, and
for the same basic reason: so something that is (and should be)
independent remains independent unless it specifically requests
otherwise.

In this case, you can request otherwise on a case-by-case basis using a
qualified name for the function. You can also do so on a more
generalized basis with a using declaration:

class derived : public base {
using base::add_record;

add_record(rect);
};

With code like this, any add_record in base is considered part of the
overload set for uses of the name add_record in derived, so if one of
them fits better than any version of add_record in derived, it'll be
used. Keep in mind, however, that with this, you've bound your derived
and base classes together a bit more closely -- changes in the base
class can now affect the behavior of the derived class in ways that
wouldn't otherwise be the case.
It's OK if I put base:add_record(rec) or if I change the name of the
base class function to "add_rec".

Am I wrong to think that is unambiguous overloading or is g++ wrong?

You're wrong and it's right. If it's any comfort, however, this question
arises quite frequently, and most of the people who raise it are not
ignorant newbies or anything like that either.
 
T

toadwarble

* toadwarble:















"add_record" in "derived1" hides the "add_record" in "base".

You can either qualify the call with class name,

base::add_record( rec );

which can alternatively be done via "derived1" wrapper,

void add_record( recordclass const& r ) { base::add_record( r ); }

or call via a "base" reference or pointer,

base& super = *this;
super.add_record (rec );

or bring the "base::add_record" overloads into "derived1" via a "using"
declaration

class derived1: public base
{
protected:
using base::add_record;
public:
void add_record( rectype_t const );
};

The FAQ item discussing this is found at <url:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9>.

It doesn't discuss the reason why the language is this way. It's simply
a more or less arbitrary choice of one evil instead of another. With
the current rules, an introduction or removal of an overload in the base
class won't affect which function is called in a derived class, except
when you use the "using" solution where you say OK, fine by me.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Thanks. It seems my example is an easier case to deal with that the
example on the URL you gave because the compiler chokes on my case
whereas potentially in the illustrated case you could have your
program build with some nasty unintended conversions, the wrong
function called and mysterious bugs if warnings weren't turned on.

(Yes I do build with -Wall and make it a policy never to have any
warnings in he finished code).

John Collins
Xi Software Ltd
 

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

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top