Ok, when I began to implement it, I thought it should be
straightforward and easy. I'm not sure whats wrong with the following
code:

class A
{
public:
A() {}
int get()
{
int a;
get(a);
return a;
}
protected:
virtual void get(int&) = 0;
};

class B : public A
{
public:
B(int a) : b(a) {}
private:
void get(int& a)
{
a = b;
}
int b;
};

int main() {
B b(1);
b.get();// thats a problem, and I dont know why
}

For some reason I dont understand yet the compiler can't "find" the
inherited methode "int get()". I use g++ version 4.1.2 20070925.

"rogo" <d.rogowski@velian.dewrote in message
news:1193845033.943109.50860@o3g2000hsb.googlegrou ps.com...

Ok, when I began to implement it, I thought it should be
straightforward and easy. I'm not sure whats wrong with the following
code:
>
class A
{
public:
A() {}
int get()
{
int a;
get(a);
return a;
}
protected:
virtual void get(int&) = 0;
};

When the complier gets here it sees everything that A has, and there is no
::get(int) or A::get(int). In other words, there is no get(int) within
scope that get() can call.

Inherited classes can call functions from base classes, but base classes can
not normally call functions within derived classes.

>
class B : public A
{
public:
B(int a) : b(a) {}
private:
void get(int& a)
{
a = b;
}
int b;
};
>
int main() {
B b(1);
b.get();// thats a problem, and I dont know why
}
>
For some reason I dont understand yet the compiler can't "find" the
inherited methode "int get()". I use g++ version 4.1.2 20070925.

rogo wrote:

Ok, when I began to implement it, I thought it should be
straightforward and easy. I'm not sure whats wrong with the following
code:
>
class A
{
public:
A() {}
int get()
{
int a;
get(a);
return a;
}
protected:
virtual void get(int&) = 0;
};
>
class B : public A
{
public:
B(int a) : b(a) {}

using A::get();

private:
void get(int& a)
{
a = b;
}
int b;
};
>
int main() {
B b(1);
b.get();// thats a problem, and I dont know why
}
>
For some reason I dont understand yet the compiler can't "find" the
inherited methode "int get()". I use g++ version 4.1.2 20070925.
>

Behavior is correct. The declaration of B::get(int&) hides all other
instances of get() for B. You have two choices: put a using declaration
in all your child classes (see above), or rename get(int&). The second
is a better solution, especially since get(int&) is private.

On Wed, 31 Oct 2007 09:06:22 -0700, "Jim Langston"
<tazmaster@rocketmail.comwrote:

>Inherited classes can call functions from base classes, but base classes can
>not normally call functions within derived classes.

I think I take issue with you regarding the phrasing of that; surely
the entire _point_ of virtual functions, for example, is to allow the
derived class to replace or augment the implementation provided by the
base class, i.e. the base class is calling functions withing the
derived class?
--
PGP key ID 0xEB7180EC

"Keith Willis" <me@privacy.netwrote in message
news:g2bhi3hf4s3triih69396lsgboovvquvj6@4ax.com...

On Wed, 31 Oct 2007 09:06:22 -0700, "Jim Langston"
<tazmaster@rocketmail.comwrote:
>

>
I think I take issue with you regarding the phrasing of that; surely
the entire _point_ of virtual functions, for example, is to allow the
derived class to replace or augment the implementation provided by the
base class, i.e. the base class is calling functions withing the
derived class?

No. Because with a polymorphism you create a derived class, not a base
class. It is the derived class's functions you are calling not the base
classes.

He is trying to call a base class function that calls a derived classes
function, which is normally not done. A base class knows nothing of the
classes that derive from it. The derived classes know of the base class
they derive from.

Jim Langston schrieb:

A base class knows nothing of the
classes that derive from it. The derived classes know of the base class
they derive from.

That's not true. The declaration of "virtual void get(int&) = 0;"
ensures that subclasses have to implement the declared method. So the
base class knows a method implementation exists in all derived
classes.

He is trying to call a base class function that calls a derived classes
function, which is normally not done.

I object to that too. It's the concept of the Template Method Pattern
(1) combined with standard inheritance. It should work and in other
object oriented languages it does. So, why not in C++?

(1) Gamma, E. et alii (2004): Design Patterns Elements of Reusable
Object-Oriented Software, 31st Printing, Boston u.a.

red floyd schrieb:

Behavior is correct. The declaration of B::get(int&) hides all other
instances of get() for B. You have two choices: put a using declaration
in all your child classes (see above), or rename get(int&). The second
is a better solution, especially since get(int&) is private.

Your second solution is exactly what I did. But I'm still curious why
A::get() gets hidden for B. Is this behaviour standard compliant?

On Nov 1, 11:39 am, rogo <d.rogow...@velian.dewrote:

red floyd schrieb:
>

>
Your second solution is exactly what I did. But I'm still curious why
A::get() gets hidden for B. Is this behaviour standard compliant?

A::get() is hidden within B's namespace, because C++ does not support
overloading across namespace scopes. Please see

http://www.research.att.com/~bs/bs_f...verloadderived

for further information.

--
For more than 4 generations the IT Professionals were the guardians
of quality and stability in software. Before the dark times.
Before Microsoft...

"rogo" <d.rogowski@velian.dewrote in message
news:1193912620.600033.314740@22g2000hsm.googlegro ups.com...

>
Jim Langston schrieb:

>
That's not true. The declaration of "virtual void get(int&) = 0;"
ensures that subclasses have to implement the declared method. So the
base class knows a method implementation exists in all derived
classes.
>

>
I object to that too. It's the concept of the Template Method Pattern
(1) combined with standard inheritance. It should work and in other
object oriented languages it does. So, why not in C++?
>
(1) Gamma, E. et alii (2004): Design Patterns Elements of Reusable
Object-Oriented Software, 31st Printing, Boston u.a.

The question isn't what should work, but what does work. My statements are
applying to how C++ works, not how other languages work or how you think C++
should work. There is enough to dicuss in C++ currently without discussing
what shoulda, woulda, coulda been in it. comp.std.c++ is the forum to
discuss those issues.

On Nov 1, 11:39 am, rogo <d.rogow...@velian.dewrote:

red floyd schrieb:

Your second solution is exactly what I did. But I'm still
curious why A::get() gets hidden for B. Is this behaviour
standard compliant?

It's what the standard requires. The situation is somewhat
complicated by ADL, but in general, lookup works its way through
a series of scopes, stopping at the first scope where it finds
the symbol.

The reason for this simple. Consider the following code:

class Base
{
public:
virtual void f() = 0 ;

} ;
class Derived : public Base
{
public:
void f() { call g( 'a' ) ; }

private:
void g( int ) ;
} ;

Obviously, the implementation of f() wants to use the private
function g, which is part of the implementation. Now, what
will happen if Base is modified to add a new function:

class Base
{
public:
void g( char ) { f() ; }
}

Adding such a simple function to base shouldn't break the
derived classes, should it? (If name lookup didn't stop in
when it found the g in Derived, this change would result in
infinite recursion in Derived.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jim Langston wrote:

"rogo" <d.rogowski@velian.dewrote in message
news:1193912620.600033.314740@22g2000hsm.googlegro ups.com...

[snip]

>
The question isn't what should work, but what does work. My statements are
applying to how C++ works, not how other languages work or how you think C++
should work. There is enough to dicuss in C++ currently without discussing
what shoulda, woulda, coulda been in it. comp.std.c++ is the forum to
discuss those issues.

Do you mean his attempt to implement the Template Method Pattern,
besides for his mistake with hiding a name of the function, is wrong in
C++? That it's something wrong with such code:

class Base
{
public:
void f()
{
g();
}
private:
virtual void g() = 0;
};

class Derived: public Base
{
private:
virtual void g()
{
// some implementation
}
};

If so, I strongly object.
--
Tadeusz B. Kopec (tkopec@NOSPAMPLEASElife.pl)

First rule of optimization: Don't do it.
Second rule of optimization (advanced): Don't do it yet.

"Tadeusz Kopec" <tkopec@NOSPAMPLEASElife.plwrote in message
news:472b65c6$1@news.home.net.pl...

Jim Langston wrote:

[snip]

>
Do you mean his attempt to implement the Template Method Pattern,
besides for his mistake with hiding a name of the function, is wrong in
C++? That it's something wrong with such code:
>
class Base
{
public:
void f()
{
g();
}
private:
virtual void g() = 0;
};
>
class Derived: public Base
{
private:
virtual void g()
{
// some implementation
}
};
>
If so, I strongly object.

Here Base is calling one of it's OWN methods, which may (will) be
overridden.