Two questions on the proposed resolution for DR 45:

1) The first proposed amendment to class.access is to add:

"A member of a class can also access all names as the class of which it
is a member. A local class of a member function may access the same
names that the member function itself may access. [Footnote: Access
permissions are thus transitive and cumulative to nested and local
classes.]"

"A member of a class" can also mean a completely unrelated class, can it
not? For example:

class T
{
// ... whatever ...
};

class U
{
   T t;
};

't' is a member of U - does that mean that it has access to U's members?
I doubt that is the intent of the proposed amendment, yet the proposed
wording seems to imply that it does.

How about restricting the wording a little:

"A member of a nested class can..."

In any case, even if I'm wrong and t cannot access U's members, I think
adding the word "nested" makes the intent of the sentence much clearer.
I had to read it three or for times and write out an example before I
figured out the intent.

2) Were there any strong reasons that the alternate proposal by Alan
Griffiths and Mark Radford (N1268) was not adopted? I know I'm dredging
up a discussion that was probably laid to rest over three years ago, but
I'm hoping someone remembers the discussion ;=)

N1268 covers the same points as the proposed resolution (N1254), but has
a far less invasive reach. In other words, if N1268 were to be adopted,
it would be trivial to later adopt N1254. On the other hand, adopting
N1254 effectively closes the door to adopting N1268. Consider:

class Outer
{
   class FirstInner
   {
     friend class Outer;
   };
   class SecondInner
   {
   };
};

Under N1268, SecondInner does not have any special privileges WRT
FirstInner, unless FirstInner explicitly grants them:
class Outer
{
   class SecondInner;
   class FirstInner
   {
     friend class Outer;
     friend class SecondInner;
   };
...

and that, IMO, is the way it should be - a class declares who its
friends are, regardless whether the class is "free-standing" or nested
inside another class.

If N1268 is found to be insufficient and it is later decided to adopt
N1254, then the above code still works, and the "friend class
SecondInner;" declaration is simply redundant.

Under N1254, though, if FirstInner declars Outer to be a friend, then
because of the transitivity granted in the amendment quoted above,
SecondInner is automatically granted access to all members of FirstInner
- and there is no way to prevent that. Worse, if it turns out allowing
this transitivity is a mistake, then any changes to the standard will
break any code which takes advantage of the implicit friendship.

Wouldn't it be prudent to take the more conservative approach of N1268,
since it solves all the same problems?

--
Jim

---
[ 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                       ]

To moderator: Sorry, my first message was incomplete, I pressed "send"
by mistake.  Could you please not let it through?  Thanks.

"Jim Hyslop" <jhyslop@ieee.org> wrote...
> Two questions on the proposed resolution for DR 45:
>
> 1) The first proposed amendment to class.access is to add:
>
> "A member of a class can also access all names as the class of which it
> is a member. A local class of a member function may access the same
> names that the member function itself may access. [Footnote: Access
> permissions are thus transitive and cumulative to nested and local
> classes.]"
>
> "A member of a class" can also mean a completely unrelated class, can it
> not?

No, it cannot.  Not a class.  In your example, it's an object.

> For example:
>
> class T
> {
> // ... whatever ...
> };
>
> class U
> {
>    T t;
> };
>
> 't' is a member of U - does that mean that it has access to U's members?

Yes, 't' is a member, 'T', however, is not a member.

> I doubt that is the intent of the proposed amendment, yet the proposed
> wording seems to imply that it does.

Yes, 't' has access.  It doesn't mean, however, that any member of 'T' has
access.  In order for 't' to access any members of 'U', it has to do it
through its own member function.  A member of 'T' is not a member of 'U',
so while 't' has theoretical access to 'U's members, there is no way for
it to accomplish that.

>
> How about restricting the wording a little:
>
> "A member of a nested class can..."

I see no need in that, to be honest.

> In any case, even if I'm wrong and t cannot access U's members, I think
> adding the word "nested" makes the intent of the sentence much clearer.
> I had to read it three or for times and write out an example before I
> figured out the intent.
>
> 2) Were there any strong reasons that the alternate proposal by Alan
> Griffiths and Mark Radford (N1268) was not adopted? I know I'm dredging
> up a discussion that was probably laid to rest over three years ago, but
> I'm hoping someone remembers the discussion ;=)
>
> N1268 covers the same points as the proposed resolution (N1254), but has
> a far less invasive reach. In other words, if N1268 were to be adopted,
> it would be trivial to later adopt N1254. On the other hand, adopting
> N1254 effectively closes the door to adopting N1268. Consider:
>
> class Outer
> {
>    class FirstInner
>    {
>      friend class Outer;
>    };
>    class SecondInner
>    {
>    };
> };
>
> Under N1268, SecondInner does not have any special privileges WRT
> FirstInner, unless FirstInner explicitly grants them:
> class Outer
> {
>    class SecondInner;
>    class FirstInner
>    {
>      friend class Outer;
>      friend class SecondInner;
>    };
> ...
>
> and that, IMO, is the way it should be - a class declares who its
> friends are, regardless whether the class is "free-standing" or nested
> inside another class.

But it still is precisely that.  Granting nested classes access to members
of the enclosing class doesn't extend those permissions _into_ the nested
classes.  The whole idea is that 'SecondInner' can see 'FirstInner', but
not into it.  Under the old Standard unless 'SecondInner' was declared
a friend of 'Outer', it couldn't even know that there was 'FirstInner',
IIRC.

Victor

---
[ 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                       ]

===================================== MODERATOR'S COMMENT:
 Please avoid over-quoting.


===================================== END OF MODERATOR'S COMMENT
"Jim Hyslop" <jhyslop@ieee.org> wrote...
> Two questions on the proposed resolution for DR 45:
>
> 1) The first proposed amendment to class.access is to add:
>
> "A member of a class can also access all names as the class of which it
> is a member. A local class of a member function may access the same
> names that the member function itself may access. [Footnote: Access
> permissions are thus transitive and cumulative to nested and local
> classes.]"
>
> "A member of a class" can also mean a completely unrelated class, can it
> not? For example:
>
> class T
> {
> // ... whatever ...
> };
>
> class U
> {
>    T t;
> };
>
> 't' is a member of U - does that mean that it has access to U's members?

Oh, it does.  But how would that be accomplished?  Only through its member
function call, right?  But T::member is not a member of U, is it?  So, while
't' is theoretically allowed to access any member of 'U', in practice there
is no way for it to do so.

> I doubt that is the intent of the proposed amendment, yet the proposed
> wording seems to imply that it does.

Well, I don't see any problem there.

>
> How about restricting the wording a little:
>
> "A member of a nested class can..."
>
> In any case, even if I'm wrong and t cannot access U's members, I think
> adding the word "nested" makes the intent of the sentence much clearer.
> I had to read it three or for times and write out an example before I
> figured out the intent.
>
> 2) Were there any strong reasons that the alternate proposal by Alan
> Griffiths and Mark Radford (N1268) was not adopted? I know I'm dredging
> up a discussion that was probably laid to rest over three years ago, but
> I'm hoping someone remembers the discussion ;=)
>
> N1268 covers the same points as the proposed resolution (N1254), but has
> a far less invasive reach. In other words, if N1268 were to be adopted,
> it would be trivial to later adopt N1254. On the other hand, adopting
> N1254 effectively closes the door to adopting N1268. Consider:
>
> class Outer
> {
>    class FirstInner
>    {
>      friend class Outer;
>    };
>    class SecondInner
>    {
>    };
> };
>
> Under N1268, SecondInner does not have any special privileges WRT
> FirstInner, unless FirstInner explicitly grants them:
> class Outer
> {
>    class SecondInner;
>    class FirstInner
>    {
>      friend class Outer;
>      friend class SecondInner;
>    };
> ...
>
> and that, IMO, is the way it should be - a class declares who its
> friends are, regardless whether the class is "free-standing" or nested
> inside another class.
>
> If N1268 is found to be insufficient and it is later decided to adopt
> N1254, then the above code still works, and the "friend class
> SecondInner;" declaration is simply redundant.
>
> Under N1254, though, if FirstInner declars Outer to be a friend, then
> because of the transitivity granted in the amendment quoted above,
> SecondInner is automatically granted access to all members of FirstInner
> - and there is no way to prevent that. Worse, if it turns out allowing
> this transitivity is a mistake, then any changes to the standard will
> break any code which takes advantage of the implicit friendship.
>
> Wouldn't it be prudent to take the more conservative approach of N1268,
> since it solves all the same problems?
>
> --
> Jim
>
> ---
> [ 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                       ]
>

---
[ 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                       ]