Pimpl idiom in MC++ classes

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

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++ ?
 
Edward said:
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++ ?
Click to expand...

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 said:
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);
}
Click to expand...

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 don't think this should work. X does not have access to X::Z which is
private to X

Ditto. No access to X::Z or x.g, both of which are private.
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.
Click to expand...

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.
 
Edward said:
I had never used pImpl as a nested class, but rather as a separate class
which is a friend to its host class.
Click to expand...

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.
Click to expand...

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 said:
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.
Click to expand...

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 ?
 
Edward said:
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 ?
Click to expand...

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
 
Edward said:
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 ?
Click to expand...

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.
 
Carl said:
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.
Click to expand...

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.
 
Doug said:
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.
Click to expand...

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 !
 
Back
Top