Pimpl idiom in MC++ classes

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++ ?

re: Pimpl idiom in MC++ classes

Edward Diener wrote:
[color=blue]
>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++ ?[/color]

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++

re: Pimpl idiom in MC++ classes

Doug Harrison [MVP] wrote:
[color=blue]
>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);
>}[/color]

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++

re: Pimpl idiom in MC++ classes

Doug Harrison [MVP] wrote:[color=blue]
> Doug Harrison [MVP] wrote:
>[color=green]
>> 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 {};[/color][/color]

I don't think this should work. X does not have access to X::Z which is
private to X
[color=blue][color=green]
>>
>> public:
>>
>> void f(X& x)
>> {
>> X::Z z;
>> x.g(z);[/color][/color]

Ditto. No access to X::Z or x.g, both of which are private.
[color=blue][color=green]
>> }
>> };
>>
>> void X::f()
>> {
>> y->f(*this);
>> }[/color]
>
> 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.[/color]

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.

re: Pimpl idiom in MC++ classes

Edward Diener wrote:
[color=blue]
>I had never used pImpl as a nested class, but rather as a separate class
>which is a friend to its host class.[/color]

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.
[color=blue]
>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.[/color]

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++

re: Pimpl idiom in MC++ classes

Doug Harrison [MVP] wrote:[color=blue]
> Edward Diener wrote:[color=green]
>> 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.[/color]
>
> 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.[/color]

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 ?

re: Pimpl idiom in MC++ classes

Edward Diener wrote:[color=blue]
> Doug Harrison [MVP] wrote:[color=green]
>> Try the example I gave you. It compiles with VC 7.1 and Comeau, but
>> not VC6.[/color]
>
> 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 ?[/color]

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

re: Pimpl idiom in MC++ classes

Edward Diener wrote:
[color=blue]
>Doug Harrison [MVP] wrote:[color=green]
>> Edward Diener wrote:[color=darkred]
>>> 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.[/color]
>>
>> 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.[/color]
>
>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 ?[/color]

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++

re: Pimpl idiom in MC++ classes

Carl Daniel [VC++ MVP] wrote:[color=blue]
> Edward Diener wrote:[color=green]
>> Doug Harrison [MVP] wrote:[color=darkred]
>>> Try the example I gave you. It compiles with VC 7.1 and Comeau, but
>>> not VC6.[/color]
>>
>> 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 ?[/color]
>
> 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.[/color]

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.

re: Pimpl idiom in MC++ classes

Doug Harrison [MVP] wrote:[color=blue]
> Edward Diener wrote:
>[color=green]
>> Doug Harrison [MVP] wrote:[color=darkred]
>>> 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.[/color]
>>
>> 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 ?[/color]
>
> 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.[/color]

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 !