can't access parent classes private member (VC6)

[Gernot Frisch]

This code works on VC7.1. But VC6 refuses to compile.

class foo
{
class bar
{
friend class foo;
foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

error C2248: 'poo' : cannot access private member declared in class
'foo'
What can I doo?

--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

________________________________________
Looking for a good game? Do it yourself!
GLBasic - you can do
www.GLBasic.com

[peter koch]

Gernot Frisch wrote:

This code works on VC7.1. But VC6 refuses to compile.

class foo
{
class bar
{
friend class foo;
foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

error C2248: 'poo' : cannot access private member declared in class
'foo'
What can I doo?

You allow foo access to bar, but let bar access foo.

/Peter
[snip]

[Victor Bazarov]

Gernot Frisch wrote:

This code works on VC7.1. But VC6 refuses to compile.

class foo
{
class bar
{
friend class foo;
foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

error C2248: 'poo' : cannot access private member declared in class
'foo'
What can I doo?

Declare classs bar as a friend of foo:

class foo
{
class bar; // forward-declaration of a member
friend class bar;

class bar
{
friend class foo;
// ^^^^^^^^^^^^^^^^
// do you really need this here?

foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

The other option is to abandon this outdated compiler for good.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Rolf Magnus]

Gernot Frisch wrote:

This code works on VC7.1. But VC6 refuses to compile.

class foo
{
class bar
{
friend class foo;
foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

error C2248: 'poo' : cannot access private member declared in class
'foo'
What can I doo?

The same you can do to make any other class access that member: Make the
member public or make bar a friend of foo.

[Gernot Frisch]

"Victor Bazarov" <v.********@comAcast.net> schrieb im Newsbeitrag
news:e3**********@news.datemas.de...

Gernot Frisch wrote:

This code works on VC7.1. But VC6 refuses to compile.

class foo
{
class bar
{
friend class foo;
foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

error C2248: 'poo' : cannot access private member declared in class
'foo'
What can I doo?

Declare classs bar as a friend of foo:

class foo
{
class bar; // forward-declaration of a member
friend class bar;

class bar
{
friend class foo;
// ^^^^^^^^^^^^^^^^
// do you really need this here?

foo & m_f;
public:
bar(foo & f) : m_f(f) {}
void wii()
{
m_f.poo(); // #error C2248
}
} m_bar;

void poo() {}

public:
foo() : m_bar(*this) {}
};

The other option is to abandon this outdated compiler for good.

This works. But now I have more questions.
class foo
{
class bar;
friend class bar;
class bar{};
};

Now, foo can access bar's private members - am I wrong? I'm a bit
confused now.

[Abdo Haji-Ali]

Gernot Frisch wrote:

This works. But now I have more questions.
class foo
{
class bar;
friend class bar;
class bar{};
};

Now, foo can access bar's private members - am I wrong? I'm a bit
confused now.

No, it's the other way around. bar can now access foo's private (and
protected) members

Abdo Haji-Ali
Programmer
In|Framez

[Gernot Frisch]

"Abdo Haji-Ali" <ah***@inframez.com> schrieb im Newsbeitrag
news:11**********************@v46g2000cwv.googlegr oups.com...

Gernot Frisch wrote:

This works. But now I have more questions.
class foo
{
class bar;
friend class bar;
class bar{};
};

Now, foo can access bar's private members - am I wrong? I'm a bit
confused now.

No, it's the other way around. bar can now access foo's private (and
protected) members

Thank you. I never had to use "friend" before.

[Lyell Haynes]

> This works. But now I have more questions.

class foo < { class bar;
friend class bar;
class bar{};
};

Now, foo can access bar's private members - am I wrong? I'm a bit
confused now.

Declaring a class as your friend means that you let _them_ access
private members of _you_, not the other way around.

Think of it like this: I give you keys to my front door, so that you
have acess to my house. I declare you as my friend by giving you the
keys. You can declare me as your friend, but that doesn't give you
access to my house. Only I can say whether you have access or not.

class A {};
class B { friend class A }; <-- A can access private members of B

Lyell

[Gernot Frisch]

Think of it like this: I give you keys to my front door, so that you
have acess to my house. I declare you as my friend by giving you the
keys. You can declare me as your friend, but that doesn't give you
access to my house. Only I can say whether you have access or not.

That's nice to remember for good.

[red floyd]

Gernot Frisch wrote:

"Abdo Haji-Ali" <ah***@inframez.com> schrieb im Newsbeitrag
news:11**********************@v46g2000cwv.googlegr oups.com...

Gernot Frisch wrote:

This works. But now I have more questions.
class foo
{
class bar;
friend class bar;
class bar{};
};

Now, foo can access bar's private members - am I wrong? I'm a bit
confused now.

No, it's the other way around. bar can now access foo's private (and
protected) members

Thank you. I never had to use "friend" before.

Easy way to remember:

Only you and your friends can play with your private parts.

[Victor Bazarov]

red floyd wrote:

[..]
Easy way to remember:

Only you and your friends can play with your private parts.

You let your friends do that? Do they enjoy it? Eek!

[red floyd]

Victor Bazarov wrote:

red floyd wrote:

[..]
Easy way to remember:

Only you and your friends can play with your private parts.

You let your friends do that? Do they enjoy it? Eek!

Only my female friends :) Of course, Mrs. red floyd doesn't need to
know about this, does she?

[Victor Bazarov]

red floyd wrote:

Victor Bazarov wrote:

red floyd wrote:

[..]
Easy way to remember:

Only you and your friends can play with your private parts.

You let your friends do that? Do they enjoy it? Eek!

Only my female friends :) Of course, Mrs. red floyd doesn't need to
know about this, does she?

My lips are private.

[amigo1]

Gernot Frisch wrote:

This code works on VC7.1. But VC6 refuses to compile.

I faced similar issue with different versions of gcc.
There seems to be a change in c++ standard which makes Nested class a
friend of Nestee by default.
VC7.1 is probably compliant to the latest standard while VC6 is not.
See : http://gcc.gnu.org/ml/gcc-bugs/2005-06/msg00458.html

[Pete C]

am****@gmail.com wrote:

There seems to be a change in c++ standard which makes Nested class a
friend of Nestee by default.

Could you cite a reference for this please? In ISO/IEC 14882:2003 there
is an example in 11.8.1 (yes yes I know the examples are
non-normative):

class E {
int x;
class B { };
class I {
// error: E::B is private
B b;
int y;
void f(E* p, int i)
{
// error: E::x is private
p->x = i;
}
};
int g(I* p)
{
// error: I::y is private
return p->y;
}
};
Well of the three supposed 'errors' above, only the final one is
considered an error by any of the modern compilers! Where did this
change happen?

Thanks...

[Ian Collins]

Pete C wrote:

am****@gmail.com wrote:

There seems to be a change in c++ standard which makes Nested class a
friend of Nestee by default.

Could you cite a reference for this please? In ISO/IEC 14882:2003 there
is an example in 11.8.1 (yes yes I know the examples are
non-normative):

class E {
int x;
class B { };
class I {
// error: E::B is private
B b;
int y;
void f(E* p, int i)
{
// error: E::x is private
p->x = i;
}
};
int g(I* p)
{
// error: I::y is private
return p->y;
}
};
Well of the three supposed 'errors' above, only the final one is
considered an error by any of the modern compilers! Where did this
change happen?

It hasn't yet, it's a proposed change that most compiler have implemented.

--
Ian Collins.

[amigo1]

According to Wolfgang Bangerth in the link I posted: "It is part of the
Technical Corrigendum TC1 of the standard, however, and therefore
(retroactively) considered part of C++98"

I am curious to know that if some thing goes into a TC is it equivalent
to being the standard or is it still in the 'proposed' status.
It's important to know because I have migrated to a higher version of
the compiler rather than changing my code.

Thanks,
-A

[Ian Collins]

am****@gmail.com wrote:

According to Wolfgang Bangerth in the link I posted: "It is part of the
Technical Corrigendum TC1 of the standard, however, and therefore
(retroactively) considered part of C++98"

I am curious to know that if some thing goes into a TC is it equivalent
to being the standard or is it still in the 'proposed' status.
It's important to know because I have migrated to a higher version of
the compiler rather than changing my code.

Please see <http://cfaj.freeshell.org/google/> for posting guidelines.

It was a feature implemented by a number of compilers (probably first in
gcc?) that doesn't break existing code, so other vendors have followed
in the name of compatibility :)

--
Ian Collins.

[Tom Widmer]

am****@gmail.com wrote:

According to Wolfgang Bangerth in the link I posted: "It is part of the
Technical Corrigendum TC1 of the standard, however, and therefore
(retroactively) considered part of C++98"
That isn't actually true - it isn't part of TC1. Rather, it has been
voted into the working paper for the next standard, which means it will
be in the next standard. See here:
http://www.open-std.org/jtc1/sc22/wg...efects.html#45
I am curious to know that if some thing goes into a TC is it equivalent
to being the standard or is it still in the 'proposed' status.

It is equivalent to being in the standard. TCs are for corrections to
defects in the standard, and in effect modify the original standard when
they are released. However, this issue didn't get solved for TC1,
presumably because it wasn't actually a defect in the original standard,
but rather an improvement to the standard and thus a candidate for the
next standard (called C++0x colloquially).

Tom