In article <im8Cb.11857$7p2.787@newsread2.news.atl.earthlink.net>,
Edward Diener <eldiener@earthlink.net> writes
>Why would a standard-complying situation mean that compilers should
>implement DR #45 ? I am not questioning that some compilers do, but maybe I
>don't understand the status of the DRs. Is it meant that compilers should
>track them in order to comply with changes to the standard and therefore
>consider themselves to be standard conformant ? From reading about the DR
>list it seems that they are changes which will most likely make it into the
>next standard rather than a list of items which compilers need to implement
>in order to be standards compliant. Very possibly I am understanding their
>status incorrectly.

You probably do understand their status however this is one of those
cases where the Standard prohibits programmers from using a mechanism
that is widespread. The choice for compiler implementers is either to
allow an enclosing class to grant friendship to a nested class (the
legacy situation which is prohibited by accident -- but the accident is
in the wording of a section of the Standard that we almost unanimously
decided we did not want to change yet again) or anticipate WG21's
decision to make the need for such a declaration unnecessary.

Personally I would prefer the second choice coupled with warnings 1)
about wrongly declared friend ship 2) use of access without a friend
declaration. This will encourage programmers to move their code towards
the future.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
                             or http://www.robinton.demon.co.uk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
>
> Agreed but I don't follow the reasoning behind this statement in relation to
> my previous comment. In the current 1998 standard, nested classes do not
> have access to the private or protected members of the enclosing class. So
> the impossibility which you mention above complies with the standard.

Right.

>
>>Given that fact it makes sense (to me)
>>for compilers to implement DR #45. Of course it should probably issue
>>a diagnostic but that is as far as it should, IMHO, go.
>
>
> Why would a standard-complying situation mean that compilers should
> implement DR #45 ? I am not questioning that some compilers do, but maybe I
> don't understand the status of the DRs. Is it meant that compilers should
> track them in order to comply with changes to the standard and therefore
> consider themselves to be standard conformant ? From reading about the DR
> list it seems that they are changes which will most likely make it into the
> next standard rather than a list of items which compilers need to implement
> in order to be standards compliant.

That is correct. It's what the issues list page says. There isn't any room for
interpretation. The standard says what it says. The 2003 update includes some
corrections due to DRs, but unincorporated DRs are not part of the standard. We
have had some cases where DRs were marked as ready for incorporation, only to be
withdrawn and modified (and not incorporated yet).

A compiler can do what it wants, but to conform to the C++ standard, it must
issue a diagnostic message about access violations. Having done so, it can
accept the code or not. The standard does not require that invalid programs be
rejected.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <im8Cb.11857$7p2.787@newsread2.news.atl.earthlink.net>,
> Edward Diener <eldiener@earthlink.net> writes
>> Why would a standard-complying situation mean that compilers should
>> implement DR #45 ? I am not questioning that some compilers do, but
>> maybe I don't understand the status of the DRs. Is it meant that
>> compilers should track them in order to comply with changes to the
>> standard and therefore consider themselves to be standard conformant
>> ? From reading about the DR list it seems that they are changes
>> which will most likely make it into the next standard rather than a
>> list of items which compilers need to implement in order to be
>> standards compliant. Very possibly I am understanding their status
>> incorrectly.
>
> You probably do understand their status however this is one of those
> cases where the Standard prohibits programmers from using a mechanism
> that is widespread.

Even if the mechanism is widespread because of non-conforming compilers,
that would be no reason to have it be standardized. Is C++ merely a
popularity contest rather than an effort to establish a coherent computer
language ?

> The choice for compiler implementers is either to
> allow an enclosing class to grant friendship to a nested class (the
> legacy situation which is prohibited by accident -- but the accident
> is in the wording of a section of the Standard that we almost
> unanimously decided we did not want to change yet again)

I didn't know that the standard forbids friendship to a nested class. Would
you please explain this ?

> or
> anticipate WG21's decision to make the need for such a declaration
> unnecessary.

I thought it was a pretty strong idea that nested classes have no
particularly priveleged access to the enclosing class, unless of course
granted friendship. It enforced a boundary which I viewed as pretty logical.

>
> Personally I would prefer the second choice coupled with warnings 1)
> about wrongly declared friend ship 2) use of access without a friend
> declaration. This will encourage programmers to move their code
> towards the future.

It seems to me that 1), the current standard, is more flexible. With 1) a
nested class does not have access to the enclosed class's methods and data,
but friendship can be granted. With 2) a nested class does have access to
the enclosed class's methods and data but this can not be taken away.
Clearly 1), rightly or wrongly by C++'s original logic, is more flexible.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <voxCb.199$im.142@newsread2.news.atl.earthlink.net>, Edward
Diener <eldiener@earthlink.net> writes
>Francis Glassborow wrote:
>> In article <im8Cb.11857$7p2.787@newsread2.news.atl.earthlink.net>,
>> Edward Diener <eldiener@earthlink.net> writes
>>> Why would a standard-complying situation mean that compilers should
>>> implement DR #45 ? I am not questioning that some compilers do, but
>>> maybe I don't understand the status of the DRs. Is it meant that
>>> compilers should track them in order to comply with changes to the
>>> standard and therefore consider themselves to be standard conformant
>>> ? From reading about the DR list it seems that they are changes
>>> which will most likely make it into the next standard rather than a
>>> list of items which compilers need to implement in order to be
>>> standards compliant. Very possibly I am understanding their status
>>> incorrectly.
>>
>> You probably do understand their status however this is one of those
>> cases where the Standard prohibits programmers from using a mechanism
>> that is widespread.
>
>Even if the mechanism is widespread because of non-conforming compilers,
>that would be no reason to have it be standardized. Is C++ merely a
>popularity contest rather than an effort to establish a coherent computer
>language ?

To understand how we got where we are you have to know a little history.
Back in the early days a lexically nested class was treated the same way
as a lexically nested struct is in C -- just treated as a lexical
convenience whilst semantically being equivalent to its
declaration/definition in the enclosing scope. IOWs at that time a
'nested' class was not a member so obviously required friendship if it
was to access the lexically enclosing class' private parts.

At some stage in the late 80s or early 90s nested classes were made
members of their enclosing classes but (I suspect without much thought)
were made second class citizens in that they had no member privileges.

At that time that did not matter much because friend qualification
seemed fine. Rather latter an issue arose concerning friends injecting
names into outer scopes (particularly in the case of templates) which
resulted in rewording the way friend declarations worked.

It was only after the C++ Standard had been released that someone
realised that the new wording actually disallowed granting friendship
inwards but only allowed granting it sideways or outwards. While we were
struggling with this clear defect (which was among several concerning
friend and allied subjects) Martin O'Riordan wrote a paper demonstrating
that the failure to make nested classes full members resulted in
sometimes requiring the exposure of implementation details of nested
classes (e.g. when a nested class used a helper class nested inside it)
because friendship is not transitive.

To most of us that was a clear indication that the real cause of the
problem was that nested classes did not have full member privileges. Any
other tinkering than simply correcting this defect would likely just
result in further defects because we would be treating the symptoms
rather than the cause.

>
>> The choice for compiler implementers is either to
>> allow an enclosing class to grant friendship to a nested class (the
>> legacy situation which is prohibited by accident -- but the accident
>> is in the wording of a section of the Standard that we almost
>> unanimously decided we did not want to change yet again)
>
>I didn't know that the standard forbids friendship to a nested class. Would
>you please explain this ?

The words of the Standard do not allow for a friend declaration for a
member of the class. This does not matter except that nested classes do
not have full member status.

>
>> or
>> anticipate WG21's decision to make the need for such a declaration
>> unnecessary.
>
>I thought it was a pretty strong idea that nested classes have no
>particularly priveleged access to the enclosing class, unless of course
>granted friendship. It enforced a boundary which I viewed as pretty logical.

It may be a strong idea but it is an erroneous one with unfortunate
consequences. If the class designer wishes to partition a class into
parts that do not have access to each other there are ways of doing it.
However that is a rare need and so it should be acceptable that it
requires more skill and understanding. If you do not want a class to
have access to the private parts of another class do not nest it there.

>
>>
>> Personally I would prefer the second choice coupled with warnings 1)
>> about wrongly declared friend ship 2) use of access without a friend
>> declaration. This will encourage programmers to move their code
>> towards the future.
>
>It seems to me that 1), the current standard, is more flexible.

How? You simply cannot have a nested class that can access the
private/protected interfaces of the enclosing class and there is no way
(within the current Standard) of providing such access other than by
moving the nested class outside and making it a non-nested class.
>With 1) a
>nested class does not have access to the enclosed class's methods and data,
>but friendship can be granted.
The Standard does not allow that and we have concluded from many hours
of consideration that the failure is caused by a fault elsewhere.
> With 2) a nested class does have access to
>the enclosed class's methods and data but this can not be taken away.
>Clearly 1), rightly or wrongly by C++'s original logic, is more flexible.

But does not go far enough and fails when the larger picture is
considered. If you do not want a nested class to have access either a)
divide the private interface into two nested classes which will not, by
default, have access to each other's protected/private interfaces or b)
do not nest the class in the first place.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
                             or http://www.robinton.demon.co.uk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage wrote:
> Edward Diener wrote:
>> Why would a standard-complying situation mean that compilers should
>> implement DR #45 ? I am not questioning that some compilers do, but
>> maybe I don't understand the status of the DRs. Is it meant that
>> compilers should track them in order to comply with changes to the
>> standard and therefore consider themselves to be standard conformant
>> ? From reading about the DR list it seems that they are changes
>> which will most likely make it into the next standard rather than a
>> list of items which compilers need to implement in order to be
>> standards compliant.
>
> That is correct. It's what the issues list page says. There isn't any
> room for interpretation. The standard says what it says. The 2003
> update includes some corrections due to DRs, but unincorporated DRs
> are not part of the standard. We have had some cases where DRs were
> marked as ready for incorporation, only to be withdrawn and modified
> (and not incorporated yet).
>
> A compiler can do what it wants, but to conform to the C++ standard,
> it must issue a diagnostic message about access violations. Having
> done so, it can accept the code or not. The standard does not require
> that invalid programs be rejected.

Thanks for the clarification.

I think the important issue from a programmer's perspective is that some
compilers may be implenting DRs by default, and this makes programming in
C++ more difficult.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <voxCb.199$im.142@newsread2.news.atl.earthlink.net>, Edward
> Diener <eldiener@earthlink.net> writes
>> Francis Glassborow wrote:
>>> In article <im8Cb.11857$7p2.787@newsread2.news.atl.earthlink.net>,
>>> Edward Diener <eldiener@earthlink.net> writes
>>>> Why would a standard-complying situation mean that compilers should
>>>> implement DR #45 ? I am not questioning that some compilers do, but
>>>> maybe I don't understand the status of the DRs. Is it meant that
>>>> compilers should track them in order to comply with changes to the
>>>> standard and therefore consider themselves to be standard
>>>> conformant ? From reading about the DR list it seems that they are
>>>> changes which will most likely make it into the next standard
>>>> rather than a list of items which compilers need to implement in
>>>> order to be standards compliant. Very possibly I am understanding
>>>> their status incorrectly.
>>>
>>> You probably do understand their status however this is one of those
>>> cases where the Standard prohibits programmers from using a
>>> mechanism that is widespread.
>>
>> Even if the mechanism is widespread because of non-conforming
>> compilers, that would be no reason to have it be standardized. Is
>> C++ merely a popularity contest rather than an effort to establish a
>> coherent computer language ?
>
> To understand how we got where we are you have to know a little
> history. Back in the early days a lexically nested class was treated
> the same way as a lexically nested struct is in C -- just treated as
> a lexical convenience whilst semantically being equivalent to its
> declaration/definition in the enclosing scope. IOWs at that time a
> 'nested' class was not a member so obviously required friendship if it
> was to access the lexically enclosing class' private parts.
>
> At some stage in the late 80s or early 90s nested classes were made
> members of their enclosing classes but (I suspect without much
> thought) were made second class citizens in that they had no member
> privileges.
>
> At that time that did not matter much because friend qualification
> seemed fine. Rather latter an issue arose concerning friends injecting
> names into outer scopes (particularly in the case of templates) which
> resulted in rewording the way friend declarations worked.
>
> It was only after the C++ Standard had been released that someone
> realised that the new wording actually disallowed granting friendship
> inwards but only allowed granting it sideways or outwards. While we
> were struggling with this clear defect (which was among several
> concerning friend and allied subjects) Martin O'Riordan wrote a paper
> demonstrating that the failure to make nested classes full members
> resulted in sometimes requiring the exposure of implementation
> details of nested classes (e.g. when a nested class used a helper
> class nested inside it) because friendship is not transitive.
>
> To most of us that was a clear indication that the real cause of the
> problem was that nested classes did not have full member privileges.
> Any other tinkering than simply correcting this defect would likely
> just result in further defects because we would be treating the
> symptoms rather than the cause.

I appreciate the explanation.

>
>>
>>> The choice for compiler implementers is either to
>>> allow an enclosing class to grant friendship to a nested class (the
>>> legacy situation which is prohibited by accident -- but the accident
>>> is in the wording of a section of the Standard that we almost
>>> unanimously decided we did not want to change yet again)
>>
>> I didn't know that the standard forbids friendship to a nested
>> class. Would you please explain this ?
>
> The words of the Standard do not allow for a friend declaration for a
> member of the class. This does not matter except that nested classes
> do not have full member status.

I had never realized this. I do realize now that I hadn't ever tried to use
the idiom of a nested class as a friend of the outer class. Instead, for the
pImpl idiom, I had used a separate class as a friend of the main class and
specified a pointer to that separate class in the main class along with a
friend declaration for the separate class in the main class. That is
definitely different from specifying my pImpl class as nested within my main
class.

>
>>
>>> or
>>> anticipate WG21's decision to make the need for such a declaration
>>> unnecessary.
>>
>> I thought it was a pretty strong idea that nested classes have no
>> particularly priveleged access to the enclosing class, unless of
>> course granted friendship. It enforced a boundary which I viewed as
>> pretty logical.
>
> It may be a strong idea but it is an erroneous one with unfortunate
> consequences. If the class designer wishes to partition a class into
> parts that do not have access to each other there are ways of doing
> it. However that is a rare need and so it should be acceptable that it
> requires more skill and understanding. If you do not want a class to
> have access to the private parts of another class do not nest it
> there.

Given that nested classes can not be declared as a friend of the enclosing
class, I agree with DR #45. From your explanation I am gathering that the
rationale for DR #45 is essentially one of:

1) the nested class is a member of the enclosing class.
2) members of the enclosing class can not be friends of the enclosing class
because they already have access to other members of the enclosing class.
3) the nested class, as a member of the enclosing class, was erroneously not
given access to the members of the enclosing class.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Has there been a suggested change to the C++ standard which allows a nested
class to access the private and protected types and members of its enclosing
class ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good Morning, Edward Diener!

Edward Diener schrieb:

> Has there been a suggested change to the C++ standard which allows a ne=
sted
> class to access the private and protected types and members of its encl=
osing
> class ?

There is no need for such a change, because standard-conforming compilers
already support this feature ;-)
Nested classes do have the same access rights as other members of a class=
: They
have access to all members of the hosting (surrounding) class. In contras=
t to
this,
the host class does not have such rights to the internals of its inner cl=
asses
(as well
as to the internals of other members it has).
Question: Do you have such problems with the MSVC 6 compiler? - ;-))

Greetings from Bremen,

Daniel Kr=FCgler (nee Spangenberg)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello!

"Edward Diener" <eldiener@earthlink.net> typed:
> Has there been a suggested change to the C++ standard which allows a
> nested class to access the private and protected types and members of
> its enclosing class ?

Yes. See the DR #45 replacement for 11.8/1:

  "A nested class is a member and as such has the same access rights
   as any other member."

Regards,
  Christoph


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr   gler (nee Spangenberg) wrote:
> Good Morning, Edward Diener!
>
> Edward Diener schrieb:
>
>> Has there been a suggested change to the C++ standard which allows a
>> nested class to access the private and protected types and members
>> of its enclosing class ?
>
> There is no need for such a change, because standard-conforming
> compilers already support this feature ;-)

Not according to the 1998 C++ Standard. But I think you are being funny, as
if to say that some compilers always supported this "feature" although it
was incorrect for the 1998 C++ Standard.

> Nested classes do have the same access rights as other members of a
> class: They have access to all members of the hosting (surrounding)
> class. In contrast to this,
> the host class does not have such rights to the internals of its
> inner classes (as well
> as to the internals of other members it has).

The latter part I understand. The former part is incorrect as of the 1998
C++ Standard but others have now informed me that DR #45 changes the
standard to conform to what you have written.

> Question: Do you have such problems with the MSVC 6 compiler? - ;-))

No, I was not using VC6 to test this. Is that one of the compilers which
incorrectly supported this prior to DR #45 and are now in conformance with
the DR #45 change?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 9 Dec 2003 04:12:21 +0000 (UTC), eldiener@earthlink.net ("Edward
Diener") wrote:

>
>The latter part I understand. The former part is incorrect as of the 1998
>C++ Standard but others have now informed me that DR #45 changes the
>standard to conform to what you have written.
>

DR #45 has "WP" status == Working Paper , which means it has become part
of a draft for a future version of the standard i.e. several years away.
It is not part of the standard yet.

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello, Edward Diener

Edward Diener schrieb:

> Daniel Kr=FCgler (nee Spangenberg) wrote:
> > Good Morning, Edward Diener!
> >
> > Edward Diener schrieb:
> >
> >> Has there been a suggested change to the C++ standard which allows a
> >> nested class to access the private and protected types and members
> >> of its enclosing class ?
> >
> > There is no need for such a change, because standard-conforming
> > compilers already support this feature ;-)
>
> Not according to the 1998 C++ Standard. But I think you are being funny=
, as
> if to say that some compilers always supported this "feature" although =
it
> was incorrect for the 1998 C++ Standard.

Of course I am funny ;-)
Sorry, I didn't want to offend you - due to my ignorance I was not aware =
of
this deficiency in C++98.

> > Nested classes do have the same access rights as other members of a
> > class: They have access to all members of the hosting (surrounding)
> > class. In contrast to this,
> > the host class does not have such rights to the internals of its
> > inner classes (as well
> > as to the internals of other members it has).
>
> The latter part I understand. The former part is incorrect as of the 19=
98
> C++ Standard but others have now informed me that DR #45 changes the
> standard to conform to what you have written.

Thanks for this information.

> > Question: Do you have such problems with the MSVC 6 compiler? - ;-))
>
> No, I was not using VC6 to test this. Is that one of the compilers whic=
h
> incorrectly supported this prior to DR #45 and are now in conformance w=
ith
> the DR #45 change?

No, it did not. In one sense it was standard conforming (relative to C++9=
8),
since it did not award (?) member access rights to inner classes (as you
showed me now), but on the other hand it was not, since it allowed to gra=
nt
friendship to inner classes (which is non-conforming). To come into defen=
se
for VC6 obviously one has to realize that according to the strict reading
of C++98 it hurts the less disturbing rule.

Thank you for your correction and please excuse my previous bantering ans=
wer.

Greetings from Bremen,

Daniel Kr=FCgler (nee Spangenberg)



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Graeme Prentice wrote:
> On Tue, 9 Dec 2003 04:12:21 +0000 (UTC), eldiener@earthlink.net
> ("Edward Diener") wrote:
>
>>
>> The latter part I understand. The former part is incorrect as of the
>> 1998 C++ Standard but others have now informed me that DR #45
>> changes the standard to conform to what you have written.
>>
>
> DR #45 has "WP" status == Working Paper , which means it has become
> part of a draft for a future version of the standard i.e. several
> years away. It is not part of the standard yet.

Understood. But there are some compilers already implementing DR #45, which
surprised me when using one of them since I had never heard of DR #45
previously to being told about it. It is possible that the compiler I am
using which does implement DR #45, does not do so in struct Ansi mode, but
given that very little compiles in that compiler in strict Ansi mode, it is
a moot point.

Allowing nested classes access to the protected and private members of its
enclosing class is quite a change from the current standard. I had no idea
that anyone had even brought this matter up. Nowadays we use some compilers
for whom we need to know Working Paper changes and not just the C++
Standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <fkkBb.7168$7p2.1531@newsread2.news.atl.earthlink.net>,
Edward Diener <eldiener@earthlink.net> writes
>Understood. But there are some compilers already implementing DR #45, which
>surprised me when using one of them since I had never heard of DR #45
>previously to being told about it. It is possible that the compiler I am
>using which does implement DR #45, does not do so in struct Ansi mode, but
>given that very little compiles in that compiler in strict Ansi mode, it is
>a moot point.
>
>Allowing nested classes access to the protected and private members of its
>enclosing class is quite a change from the current standard. I had no idea
>that anyone had even brought this matter up. Nowadays we use some compilers
>for whom we need to know Working Paper changes and not just the C++
>Standard.

Not really in this case as it is impossible for a compiler to comply
with the Standard and have a nested class access private or protected
members of the enclosing class. Given that fact it makes sense (to me)
for compilers to implement DR #45. Of course it should probably issue a
diagnostic but that is as far as it should, IMHO, go.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

eldiener@earthlink.net ("Edward Diener") wrote in message news:<fkkBb.7168$7p2.1531@newsread2.news.atl.earthlink.net>...
>
> Allowing nested classes access to the protected and private members of its
> enclosing class is quite a change from the current standard.

It is also quite a change from established (non-conforming) behaviour.

> I had no idea that anyone had even brought this matter up.

It happened some time ago.  For those interested in the history:

   http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2000/N1254.pdf
   http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2000/n1268.pdf
--
Alan Griffiths
http://www.octopull.demon.co.uk/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <fkkBb.7168$7p2.1531@newsread2.news.atl.earthlink.net>,
> Edward Diener <eldiener@earthlink.net> writes
>> Understood. But there are some compilers already implementing DR
>> #45, which surprised me when using one of them since I had never
>> heard of DR #45 previously to being told about it. It is possible
>> that the compiler I am using which does implement DR #45, does not
>> do so in struct Ansi mode, but given that very little compiles in
>> that compiler in strict Ansi mode, it is a moot point.
>>
>> Allowing nested classes access to the protected and private members
>> of its enclosing class is quite a change from the current standard.
>> I had no idea that anyone had even brought this matter up. Nowadays
>> we use some compilers for whom we need to know Working Paper changes
>> and not just the C++ Standard.
>
> Not really in this case as it is impossible for a compiler to comply
> with the Standard and have a nested class access private or protected
> members of the enclosing class.

Agreed but I don't follow the reasoning behind this statement in relation to
my previous comment. In the current 1998 standard, nested classes do not
have access to the private or protected members of the enclosing class. So
the impossibility which you mention above complies with the standard.

> Given that fact it makes sense (to me)
> for compilers to implement DR #45. Of course it should probably issue
> a diagnostic but that is as far as it should, IMHO, go.

Why would a standard-complying situation mean that compilers should
implement DR #45 ? I am not questioning that some compilers do, but maybe I
don't understand the status of the DRs. Is it meant that compilers should
track them in order to comply with changes to the standard and therefore
consider themselves to be standard conformant ? From reading about the DR
list it seems that they are changes which will most likely make it into the
next standard rather than a list of items which compilers need to implement
in order to be standards compliant. Very possibly I am understanding their
status incorrectly.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hanh Huynh Huu <hanh.huynhhuu@wanadoo.fr> writes:

> Is the following code legal ?
>
> class A {
>  class B {
>   public:
>     B f() const { return B(*this); }
>   };
> };

Yes (hopefully, a class knows itself).

OTOH, writing A::B in class B isn't.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Is the following code legal ?

class A {
 class B {
  public:
    B f() const { return B(*this); }
  };
};

My compiler complains about A::B being inaccessible in f().



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 16 Nov 1998 16:36:22 GMT, Hanh Huynh Huu <hanh.huynhhuu@wanadoo.fr> wrote:

>Is the following code legal ?
>
>class A {
> class B {
>  public:
>    B f() const { return B(*this); }
>  };
>};
>
>My compiler complains about A::B being inaccessible in f().

The code is legal.  Note that A is not accessible to A::B.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn750q6e.v4m.sbnaran@localhost.localdomain>,
Siemel Naran <sbnaran@KILL.uiuc.edu> wrote:
>On 16 Nov 1998 16:36:22 GMT, Hanh Huynh Huu <hanh.huynhhuu@wanadoo.fr> wrote:
>
>>Is the following code legal ?
>>
>>class A {
>> class B {
>>  public:
>>    B f() const { return B(*this); }
>>  };
>>};
>>
>>My compiler complains about A::B being inaccessible in f().
>
>The code is legal.  Note that A is not accessible to A::B.

Since some old compilers have problems with this I would also like to
point out that the following is also legal:

class A {
 class B {
  public:
    B f() const;
  };
};
A::B A::B::f() const {return B(*this);}

Even though A::B is private it is accessible from A::B::f and thus legal.
(The point is made clear in CD2 paragraph 11/5)


--
// Home page  http://www.dna.lth.se/home/Hans_Olsson/
// Email To..Hans.Olsson@dna.lth.se [Please no junk e-mail]



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>> =ABHanh=BB, Hanh Huynh Huu <hanh.huynhhuu@wanadoo.fr> wrote:

Hanh> Is the following code legal ?

Hanh> class A {
Hanh>  class B {
Hanh>   public:
Hanh>     B f() const { return B(*this); }
Hanh>   };
Hanh> };

This code is legal.

Hanh> My compiler complains about A::B being inaccessible in f().

It is wrong.

--=20
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]