In article <IRoHIZAjXSR4EwR5@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> writes
>And anyway, if you really, really want to limit access to the public and
>protected interface consider:
>
>class base {
>// whatever
>};
>
>class derived: public base {
>        friend class X;
>};
>
>Note that  AFAICS you can do everything with derived that you could with
>base.

To comment on my own posting;  that is not quite true if base has non-
default ctors you will have to write 'forwarding' versions for derived.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

David R Tribble <david@tribble.com> writes:
> And what if you're not the author of the class, and the author
> decides to change a member from protected to private?  I.e., how
> do you enforce the "hands off my privates" rule?

The author writes the class and its friends together. It's one piece.
---
[ 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              ]

David R Tribble <david@tribble.com> wrote in message
news:3845893D.F552A647@tribble.com...
> > What are you trying to protect?
>
> It's only one isolated example, but suppose I want a friend function
> that can only access the public and protected members of my class
> (and not have access to the private members of the class).
> I can't do that in C++.

    class myClass_private_stuff {
    protected:
        int foo_cannot_access_this;
    private:
        // Private ctor and friend, so that only myClass can use this class
        myClass_private_stuff();
        friend class myClass;
    };

    class myClass : public myClass_private_stuff {
    protected:
        int foo_can_get_this;

        friend void foo(myClass&);
        // Note that friendship is not transitive;
        // foo is a friend of myClass,
        // and myClass is friend of myClass_private_stuff,
        // but foo is not friend of myClass_private_stuff

    public:
        int access() // Member functions have full access
            { return foo_can_get_this + foo_cannot_access_this; } // OK
    };

    // Friend function has restricted access
    void foo(myClass&m) {
        int x=0;

        // Error: Private in myClass_private_stuff
        x += m.foo_cannot_access_this;

        // OK
        x += m.foo_can_get_this;
    }

BUT -- rephrasing what Steve Clamage said -- needing this technique is a
"red warning flag" that your class hierarchy needs revisiting. You might
have a class hierarchy that's ideal for Eiffel but sub-optimal for C++;
these are distinct languages, with distinct techniques. Despite the
similarities, it is very easy to design a project so that it fits in
naturally with one language and struggles against the other. Go back to
first principles in C++, if this is at all possible, and you might end up
with a totally different design. Or, if the design has gone far enough to
make this impractical, consider sticking with Eiffel -- after all, C++ isn't
perfect for every project.

Good luck.
---
[ 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              ]

David R Tribble wrote:
>
> Current C++ semantics allow a function to access all of the members
> of a class which declares it as a friend.  Has anyone proposed
> limiting the access of friend functions?
>
> For example, the following could limit foo() to accessing only
> public or protected members of Symbol:
>
>     void  foo();
>
>     class Symbol
>     {
>     protected:
>         friend void  foo();
>         ...
>     };
>

Others have pinted out that it would break a lot of code. But I often
wished that a more flexible protection mechanism existed. Since goto
labels are not allowed in a class declaration (I hope!), labels in a
class could be treated as user-defined protection levels, which would be
in addition to normal levels:

class C
{
   private:
      void internal_set_name ( const std::string & );

   name_only:   // a private and name_only section.
      std::string name;

      // now give access to internal: using "new" friend_acces keyword
      //                              to avoid clashing with old friend
usage.
      friend_access void C::internal_set_name ( const std::string & );

   private:   // reset priviledge.
 // other data.

   public:   // reset priviledge.
      void setName ( const std::string & aName )
      {
         internal_set_name ( aName );
      }
};

The advantage is that even though all internal data is in the same
class, you can put up walls between sub-division of a class.

Some other posters mentionned that you can pretty much achieve the same
result by putting the walled-off sections in different classes and
inheriting from them. While true, this can become cumbersome when you
have a many small data item that you wish to isolate. This also
encourages dividing responsabilities among classes. Nice. Now the code
looks like:

class name_only
{
   protected:
      void internal_set_name ( const std::string & );

   private:
      std::string name;
};

class C : private name_only // could be public also
{
   public:
      void setName ( const std::string & aName )
      {
         internal_set_name ( aName );
      }
};

But the trick breaks down if a single function needs to access multiple
data items that are otherwise separated. You could start multiplying
classes, but the number of combination will soon explode:

class name_only_with description: public name_only, public
description_only
{
};

// etc.


So the extension has benefits, as in the following code. Please, don't
attack the internal_set_name_descr() function on the basis that it does
two things: it is an example, but there are many times when two
unrelated data items may need to be used together to compute a result.
So the code would look like:

class C
{
   private:
      void internal_set_name_descr ( const std::string &,
                                     const std::string & );

   name_only:   // a private and name_only section.
      std::string name;

      // now give access to internal: using "new" friend_acces keyword
      //                              to avoid clashing with old friend
usage.
      friend_access void C::internal_set_name_descr ( const std::string
&,
                                                      const std::string
& );

   descr_only:   // a private and descr_only section.
      std::string description;

      // now give access to internal: using "new" friend_acces keyword
      //                              to avoid clashing with old friend
usage.
      friend_access void C::internal_set_name_descr ( const std::string
&,
                                                      const std::string
& );

   private:   // reset priviledge.
 // other data.

   public:   // reset priviledge.
      void setNameDescr ( const std::string & aName,
                          const std::string & aDescr )
      {
         internal_set_name ( aName, aDescr );
      }
};


This is the kind of code I wish I could write: simple, clear, secure.


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

Steve Clamage wrote:
>
> David R Tribble wrote:
>> Current C++ semantics allow a function to access all of the members
>> of a class which declares it as a friend.  Has anyone proposed
>> limiting the access of friend functions?
>
> Frequently, but it has always seemed to me to be pointless.
>
> If you want to limit access of friend functions, wouldn't you also
> want to limit access of member functions?  Yet no one (AFAIK) has
> ever suggested limiting access of member functions.

Other O-O languages, such as Eiffel, do restrict member functions
from accessing non-public members of objects other than 'this' (which
are the same type as 'this').  In order for a class member function
to access a private variable of another object of the same class
type, that function must effectively be declared a "friend" of
the class.

Such languages have a more restrictive view of member access than
C++.

> I think the desire to limit access of friends must come from an
> improper understanding of the purpose of friends. IMHO, friends
> are best understood as being part of the public interface of the
> class, and part of the class implementation. They are equivalent
> to static member functions, except for the syntax that you use
> when calling them.
>
> No function is a friend unless explcitly declared so, just as no
> function is a member unless explicitly declared so. As the owner
> of the class, you have complete control over all members and
> friends of the class. Why would you want to limit access of just
> one category of function, or of any function, for that matter?
>
> The point of access restriction is to protect non-owners from
> depending on non-public interfaces, or from violating consistency
> requirements. If you are writing the class implementation,
> presumably you understand those issues.

Designers of other languages might argue that C++ has too loose
a view of member access to begin with; specifically, that it allows
a member function of a class to access private members of objects
other than 'this'.  C++ programmers would probably argue that this
is an advantage instead of a disadvantage.  (I don't take either
position; each scheme has its pros and cons.)

> What are you trying to protect?

It's only one isolated example, but suppose I want a friend function
that can only access the public and protected members of my class
(and not have access to the private members of the class).
I can't do that in C++.

-- David R. Tribble, david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Steve Clamage wrote:
> >
> > David R Tribble wrote:
> >> Current C++ semantics allow a function to access all of the members
> >> of a class which declares it as a friend.  Has anyone proposed
> >> limiting the access of friend functions?
> >
> > Frequently, but it has always seemed to me to be pointless.
> >
> > If you want to limit access of friend functions, wouldn't you also
> > want to limit access of member functions?  Yet no one (AFAIK) has
> > ever suggested limiting access of member functions.
>
> Other O-O languages, such as Eiffel, do restrict member functions
> from accessing non-public members of objects other than 'this' (which
> are the same type as 'this').

But that is a completely different topic.  We were discussing whether
a friend's access should be limited by an access specification.
Whether access should be per type or per object is, I think, an
independent topic.

As a side issue, how do you write a copy constructor or
copy assignment operator under the Eiffel rule?

>
> > What are you trying to protect?
>
> It's only one isolated example, but suppose I want a friend function
> that can only access the public and protected members of my class
> (and not have access to the private members of the class).
> I can't do that in C++.

Now we are back to the beginning. Why do you want to do that?

My point is that wanting such a feature for a class implies the
design of the class is already out of control, or that the class
is too big and should logically be split up.

Assuming you have a real programming problem to solve, maybe you
should not focus on limiting access of friend functions. Might
not some other factorization of the design work at least as well?

--
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:
> It's only one isolated example, but suppose I want a friend function
> that can only access the public and protected members of my class
> (and not have access to the private members of the class).
> I can't do that in C++.

Well, since you're the author of the friend function, just don't use
any private members.


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

> > It's only one isolated example, but suppose I want a friend function
> > that can only access the public and protected members of my class
> > (and not have access to the private members of the class).
> > I can't do that in C++.

> My point is that wanting such a feature for a class implies the
> design of the class is already out of control, or that the class
> is too big and should logically be split up.


Hmmm. I used the "protected" feature in Java exhaustively. Every class
within the same package as a class having protected members/methods (or
interface), can access that class's public & protected interface (package
protection). At first it seemed really not that practical, but once you come
to think in layers (eg a database layer, operator layer, gui layer, ...)
these are very handy. So all classes in a package expose their protected
interface to the other classes within that package (and to classes deriving
from that class of course), and only the public interface to other packages
(the classes therein).

So you would place such classes within the same package.

TiTi




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

Hyman Rosen wrote:
>
> David R Tribble <david@tribble.com> writes:
> > It's only one isolated example, but suppose I want a friend function
> > that can only access the public and protected members of my class
> > (and not have access to the private members of the class).
> > I can't do that in C++.
>
> Well, since you're the author of the friend function, just don't use
> any private members.

And what if you're not the author of the class, and the author
decides to change a member from protected to private?  I.e., how
do you enforce the "hands off my privates" rule?

-- David R. Tribble, david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> David R Tribble wrote:
>>
>> Steve Clamage wrote:
>> > If you want to limit access of friend functions, wouldn't you also
>> > want to limit access of member functions?  Yet no one (AFAIK) has
>> > ever suggested limiting access of member functions.
>>
>> Other O-O languages, such as Eiffel, do restrict member functions
>> from accessing non-public members of objects other than 'this' (which
>> are the same type as 'this').
>
> But that is a completely different topic.  We were discussing whether
> a friend's access should be limited by an access specification.
> Whether access should be per type or per object is, I think, an
> independent topic.
>
> As a side issue, how do you write a copy constructor or
> copy assignment operator under the Eiffel rule?

You would make those member functions friends of the class, so
that they would have access to the private members of objects other
than 'this'.

-- David R. Tribble, david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

TiTi wrote:
>
> Hmmm. I used the "protected" feature in Java exhaustively. Every class
> within the same package as a class having protected members/methods (or
> interface), can access that class's public & protected interface (package
> protection). At first it seemed really not that practical, but once you come
> to think in layers (eg a database layer, operator layer, gui layer, ...)
> these are very handy. So all classes in a package expose their protected
> interface to the other classes within that package (and to classes deriving
> from that class of course), and only the public interface to other packages
> (the classes therein).
>

Well, I have found Java's "protected" feature's access rules a nuisance.
I don't want all classes in a package poking at each other's
implementation. Currently, there is no way in Java to expose
implementation to sub-classes only. I think they designed it so because
of the lack of friend specifiers.

--
Regards,
Biju Thomas


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

David R Tribble wrote:
>
> Hyman Rosen wrote:
> >
> > David R Tribble <david@tribble.com> writes:
> > > It's only one isolated example, but suppose I want a friend function
> > > that can only access the public and protected members of my class
> > > (and not have access to the private members of the class).
> > > I can't do that in C++.
> >
> > Well, since you're the author of the friend function, just don't use
> > any private members.
>
> And what if you're not the author of the class, and the author
> decides to change a member from protected to private?  I.e., how
> do you enforce the "hands off my privates" rule?
>

Why would that ever be the case?  People working on the implementation
of a class must understand the design, the interfaces, and the
constraints.

Discussions similar to this one seem to assume that functions and
classes are freely and arbitrarily granted friend status, without
anyone being in control. In that scenario, the project is doomed
anyway, no matter what kind of access control the language provides.

--
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3846D2E2.96D3581F@tribble.com>, David R Tribble
<david@tribble.com> writes
>> Well, since you're the author of the friend function, just don't use
>> any private members.
>
>And what if you're not the author of the class, and the author
>decides to change a member from protected to private?  I.e., how
>do you enforce the "hands off my privates" rule?

You mean you (as class designer) declare friend functions and allow
users to define them?  As always, C++ makes no attempt to protect
against stupidity (perhaps it should, what about a #pragma stupid user)
not blatant theft.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


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

david@tribble.com (David R Tribble) wrote:
> And what if you're not the author of the class, and the author
> decides to change a member from protected to private?  I.e., how
> do you enforce the "hands off my privates" rule?

To make this convincing I think you need a case where the set of friend
functions is extensible. If the set is fixed, then we can consider them
part of the class, have the class author write them all, and then we don't
need protection. Compare with subclasses: the set of subclasses is
extensible and so it makes sense to have "protected" for them.

So we need to consider allowing protected access to *template* functions.
For example, a stream class might want to give access to:

    template <typename T>
    my_ostream &operator<<( my_ostream &os, const T &t );

so that client programmers could write an unbounded number of functions,
one for each type T, and each of them having access to the protected
interface.

Does this make sense? The insinuation is that implementing operator<<()
requires more access than merely calling it. This example is dubious
because we know that std::ostream has got by without protected friend
templates and doesn't seem to have suffered. Outputting a T just means
outputting the components of T so just requires the same "outputting"
access that a caller would have. Can you think of a better example?

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."


[ 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 <3842EB2B.19BA4E02@tribble.com>, David R Tribble
<david@tribble.com> writes
>
>Current C++ semantics allow a function to access all of the members
>of a class which declares it as a friend.  Has anyone proposed
>limiting the access of friend functions?
  <snip>

Surely there are some questions that should be answered or discussed
before talking details :

  Which human errors and misbehaviour is it possible to guard against ?

  Which human errors and misbehaviour should be guarded against ?

  John
--
John Harris
  mailto:john@jgharris.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> If you want to limit access of friend functions, wouldn't you also
> want to limit access of member functions?  Yet no one (AFAIK) has
> ever suggested limiting access of member functions.

I just suggested limiting the access of member functions,
in a post wending its way here.



[ 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 <3842EB2B.19BA4E02@tribble.com>, david@tribble.com says...
>
> Current C++ semantics allow a function to access all of the members
> of a class which declares it as a friend.  Has anyone proposed
> limiting the access of friend functions?

David R Tribble wrote:
>
> Current C++ semantics allow a function to access all of the members
> of a class which declares it as a friend.  Has anyone proposed
> limiting the access of friend functions?

See Steve's comments. I generally agree with them.

However, if you insist...

You can prevent access to private members by deriving a class and making
the function a friend of the derived class:

  class Base {
  private:
     int x;
  protected:
     int y;
  };

  class JustForFriends : public Base {
     friend void foo ( JustForFriends* jff )
     {  jff->x = 1;  // error, no access
        jff->y = 2;  // ok
     }
  };

This won't work for protected members, but you don't need it to. If you
don't want a function to have access to any non-public members, just
don't make it a friend. It will still have public access, of course.

I want to stress that I don't endorse this technique. I'm just pointing
out that, for those who really feel they must have it, it's a way of
providing the desired functionality without tinkering with the standard.

Lin
--
Linda K Sherman <lindash@concentric.net>
linsherm@gte.net  www.cti-pro.com   www.dalati.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3842EB2B.19BA4E02@tribble.com>, David R Tribble
<david@tribble.com> wrote:

> Current C++ semantics allow a function to access all of the members
> of a class which declares it as a friend.  Has anyone proposed
> limiting the access of friend functions?
>
> For example, the following could limit foo() to accessing only
> public or protected members of Symbol:
>
>     void  foo();
>
>     class Symbol
>     {
>     protected:
>         friend void  foo();
>         ...
>     };

<snipped same for private, public>

In principle I think it is a good idea. Minor nitpick: Most "friend"
declarations that I write would happen to look like "public", because
usually I write public members at the end of the class, followed by friend
declarations; so they would lose all access rights. Just leave out the
colon and write

   protected friend void foo();
   private friend void bar();

That way, no current code is changed.
---
[ 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 <MPG.12acc9d18740935b98987f@news.mindspring.com>, Jerry
Coffin <jcoffin@taeus.com> writes
>IOW, I think it's a clever solution in search of a problem.
>Unfortunately, adding the solution to the standard language is likely
>to encourage the matching problem, which I'd consider a poor idea.

And anyway, if you really, really want to limit access to the public and
protected interface consider:

class base {
// whatever
};

class derived: public base {
        friend class X;
};

Note that  AFAICS you can do everything with derived that you could with
base.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


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

Current C++ semantics allow a function to access all of the members
of a class which declares it as a friend.  Has anyone proposed
limiting the access of friend functions?

For example, the following could limit foo() to accessing only
public or protected members of Symbol:

    void  foo();

    class Symbol
    {
    protected:
        friend void  foo();
        ...
    };

By symmetry, declaring a friend function following a 'public:'
modifier within a class declaration would limit the function's
access to only the public members of the class.

The following would allow foo() to access all of the members of
Mine, including private members (just like C++ allows today):

    class Mine
    {
    private:              // 'private:' is optional
        friend void  foo();
        ...
    };

-- David R. Tribble, david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Current C++ semantics allow a function to access all of the members
> of a class which declares it as a friend.  Has anyone proposed
> limiting the access of friend functions?

Frequently, but it has always seemed to me to be pointless.

If you want to limit access of friend functions, wouldn't you also
want to limit access of member functions?  Yet no one (AFAIK) has
ever suggested limiting access of member functions.

I think the desire to limit access of friends must come from an
improper understanding of the purpose of friends. IMHO, friends
are best understood as being part of the public interface of the
class, and part of the class implementation. They are equivalent
to static member functions, except for the syntax that you use
when calling them.

No function is a friend unless explcitly declared so, just as no
function is a member unless explicitly declared so. As the owner
of the class, you have complete control over all members and
friends of the class. Why would you want to limit access of just
one category of function, or of any function, for that matter?

The point of access restriction is to protect non-owners from
depending on non-public interfaces, or from violating consistency
requirements. If you are writing the class implementation,
presumably you understand those issues. What are you trying to
protect?

---
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]