Pimpl idiom in MC++ classes

[Edward Diener]

Because 'friend' is not recognized in MC++, using the pImpl idiom in MC++
classes seems nearly impossible. Normally a pImpl class is a 'friend' to the
class for which it supplies the private implementation, so that it can
access any protected members, including inherited protected members, of that
class. Without 'friend' the pImpl class can no longer do this, and it is a
PITA passing the necessary protected data or protected member function
pointers to the pImpl idiom member functions each time it may need it.

Is there a good workaround for this in MC++ ?

[Doug Harrison [MVP]]

Edward Diener wrote:

Because 'friend' is not recognized in MC++, using the pImpl idiom in MC++
classes seems nearly impossible. Normally a pImpl class is a 'friend' to the
class for which it supplies the private implementation, so that it can
access any protected members, including inherited protected members, of that
class. Without 'friend' the pImpl class can no longer do this, and it is a
PITA passing the necessary protected data or protected member function
pointers to the pImpl idiom member functions each time it may need it.

Is there a good workaround for this in MC++ ?

It seems like most of my pImpl classes don't need to be friends of their
"host" classes, but in any event, it shouldn't be necessary to make the
pImpl class a friend for it to have full access to the host class. ISTR that
VC7 tracks this DR:

http://www.comeaucomputing.com/iso/cwg_defects.html#45

So the following should work:

class X
{
private:

class Y;
Y* y;

struct Z {};

void g(Z&);

public:

void f();
};

class X::Y
{
private:

struct D : X::Z {};

public:

void f(X& x)
{
X::Z z;
x.g(z);
}
};

void X::f()
{
y->f(*this);
}

--
Doug Harrison
Microsoft MVP - Visual C++

[Doug Harrison [MVP]]

Doug Harrison [MVP] wrote:

So the following should work:

class X
{
private:

class Y;
Y* y;

struct Z {};

void g(Z&);

public:

void f();
};

class X::Y
{
private:

struct D : X::Z {};

public:

void f(X& x)
{
X::Z z;
x.g(z);
}
};

void X::f()
{
y->f(*this);
}

Sorry, that's an example for regular C++ classes, not __gc classes. To get
the latter, add the necessary __gc's and fix the declaration and usage of
'z' in X::Y::f.

--
Doug Harrison
Microsoft MVP - Visual C++

[Edward Diener]

Doug Harrison [MVP] wrote:

Doug Harrison [MVP] wrote:

So the following should work:

class X
{
private:

class Y;
Y* y;

struct Z {};

void g(Z&);

public:

void f();
};

class X::Y
{
private:

struct D : X::Z {};
I don't think this should work. X does not have access to X::Z which is
private to X

public:

void f(X& x)
{
X::Z z;
x.g(z);
Ditto. No access to X::Z or x.g, both of which are private.
}
};

void X::f()
{
y->f(*this);
}

Sorry, that's an example for regular C++ classes, not __gc classes.
To get the latter, add the necessary __gc's and fix the declaration
and usage of 'z' in X::Y::f.

I had never used pImpl as a nested class, but rather as a separate class
which is a friend to its host class. But even in the nested class situation,
a nested class does not have access to the private or protected members of
its surrounding class. Unless the rules have changed drastically somehow.

[Doug Harrison [MVP]]

Edward Diener wrote:

I had never used pImpl as a nested class, but rather as a separate class
which is a friend to its host class.
I don't think I've ever used anything but a private nested class for this,
one which I declare in the header and complete in the .cpp file, so that
it's truly hidden from users of the host class.
But even in the nested class situation,
a nested class does not have access to the private or protected members of
its surrounding class. Unless the rules have changed drastically somehow.

The rules which didn't give access to nested or local classes were never
very helpful. Like I said in my first reply:

It seems like most of my pImpl classes don't need to be friends of their
"host" classes, but in any event, it shouldn't be necessary to make the
pImpl class a friend for it to have full access to the host class. ISTR that
VC7 tracks this DR:

http://www.comeaucomputing.com/iso/cwg_defects.html#45

Try the example I gave you. It compiles with VC 7.1 and Comeau, but not VC6.

--
Doug Harrison
Microsoft MVP - Visual C++

[Edward Diener]

Doug Harrison [MVP] wrote:

Edward Diener wrote:

But even in the nested class situation,
a nested class does not have access to the private or protected
members of its surrounding class. Unless the rules have changed
drastically somehow.

The rules which didn't give access to nested or local classes were
never very helpful. Like I said in my first reply:

It seems like most of my pImpl classes don't need to be friends of
their "host" classes, but in any event, it shouldn't be necessary to
make the pImpl class a friend for it to have full access to the host
class. ISTR that VC7 tracks this DR:

http://www.comeaucomputing.com/iso/cwg_defects.html#45

Try the example I gave you. It compiles with VC 7.1 and Comeau, but
not VC6.

I am trying to understand why it compiles. Have the rules regarding access
by members of a nested class to the protected and private members and types
of its enclosing class changed ? Because that is clearly what you are doing
in the example. So when it compiles successfully in VC7.1 and Comeau, it
appears that neither are following the C++ Standard. Surely there is
something I am missing here. Have the rules changed for these compilers from
the 1998 C++ Standard ?

[Carl Daniel [VC++ MVP]]

Edward Diener wrote:

Doug Harrison [MVP] wrote:

Try the example I gave you. It compiles with VC 7.1 and Comeau, but
not VC6.

I am trying to understand why it compiles. Have the rules regarding
access by members of a nested class to the protected and private
members and types of its enclosing class changed ? Because that is
clearly what you are doing in the example. So when it compiles
successfully in VC7.1 and Comeau, it appears that neither are
following the C++ Standard. Surely there is something I am missing
here. Have the rules changed for these compilers from the 1998 C++
Standard ?

Did you read the text of DR #45? The rules _have_ radically changed, or
would under the proposed resolution which says "A nested class is a member
and as such has the same access rights as any other member.". VC and Comeau
both chose to implement the proposed rule change even though the DR is not
part of the official standard yet.

-cd

[Doug Harrison [MVP]]

Edward Diener wrote:

Doug Harrison [MVP] wrote:

Edward Diener wrote:

But even in the nested class situation,
a nested class does not have access to the private or protected
members of its surrounding class. Unless the rules have changed
drastically somehow.

The rules which didn't give access to nested or local classes were
never very helpful. Like I said in my first reply:

It seems like most of my pImpl classes don't need to be friends of
their "host" classes, but in any event, it shouldn't be necessary to
make the pImpl class a friend for it to have full access to the host
class. ISTR that VC7 tracks this DR:

http://www.comeaucomputing.com/iso/cwg_defects.html#45

Try the example I gave you. It compiles with VC 7.1 and Comeau, but
not VC6.

I am trying to understand why it compiles. Have the rules regarding access
by members of a nested class to the protected and private members and types
of its enclosing class changed ? Because that is clearly what you are doing
in the example. So when it compiles successfully in VC7.1 and Comeau, it
appears that neither are following the C++ Standard. Surely there is
something I am missing here. Have the rules changed for these compilers from
the 1998 C++ Standard ?

The code I presented is illegal by the original rules, but legal under the
resolution of the defect report I pointed you to. This DR has "WP" status,
which means:

"WP: A DR issue that the Committee has voted to apply to the current Working
Paper. The Working Paper is a draft for a future version of the Standard."

To "track this DR" is to implement the changes it proposes.

--
Doug Harrison
Microsoft MVP - Visual C++

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

Doug Harrison [MVP] wrote:

Try the example I gave you. It compiles with VC 7.1 and Comeau, but
not VC6.

I am trying to understand why it compiles. Have the rules regarding
access by members of a nested class to the protected and private
members and types of its enclosing class changed ? Because that is
clearly what you are doing in the example. So when it compiles
successfully in VC7.1 and Comeau, it appears that neither are
following the C++ Standard. Surely there is something I am missing
here. Have the rules changed for these compilers from the 1998 C++
Standard ?

Did you read the text of DR #45? The rules _have_ radically
changed, or would under the proposed resolution which says "A nested
class is a member and as such has the same access rights as any other
member.". VC and Comeau both chose to implement the proposed rule
change even though the DR is not part of the official standard yet.

Ah, now I understand. That is a pretty drastic change to C++. I am a bit
surprised it was made, although I can understand its usefulness. I obviously
didn't understand the full impact of DR #45 when I read it.

[Edward Diener]

Doug Harrison [MVP] wrote:

Edward Diener wrote:

Doug Harrison [MVP] wrote:

Edward Diener wrote:
But even in the nested class situation,
a nested class does not have access to the private or protected
members of its surrounding class. Unless the rules have changed
drastically somehow.

The rules which didn't give access to nested or local classes were
never very helpful. Like I said in my first reply:

It seems like most of my pImpl classes don't need to be friends of
their "host" classes, but in any event, it shouldn't be necessary to
make the pImpl class a friend for it to have full access to the host
class. ISTR that VC7 tracks this DR:

http://www.comeaucomputing.com/iso/cwg_defects.html#45

Try the example I gave you. It compiles with VC 7.1 and Comeau, but
not VC6.

I am trying to understand why it compiles. Have the rules regarding
access by members of a nested class to the protected and private
members and types of its enclosing class changed ? Because that is
clearly what you are doing in the example. So when it compiles
successfully in VC7.1 and Comeau, it appears that neither are
following the C++ Standard. Surely there is something I am missing
here. Have the rules changed for these compilers from the 1998 C++
Standard ?

The code I presented is illegal by the original rules, but legal
under the resolution of the defect report I pointed you to. This DR
has "WP" status, which means:

"WP: A DR issue that the Committee has voted to apply to the current
Working Paper. The Working Paper is a draft for a future version of
the Standard."

To "track this DR" is to implement the changes it proposes.

Ok, now I realize the full impact of the DR and what is meant by tracking
it. That is a big change to C++. I never realized that this had been
proposed and accepted in the Working Paper. Thanks !