stkim@yujinrobot.com ("Kim, Seungtai") writes:

> May be it just funny question.
>
> The friend makes that a function or class can access to
> invisible memebers with particular right. It works well for
> operator <<, >>, etc.
>
> In this point, the question arises. Why there is no enemy relation.

Bottom line: because it has yet to be shown to be useful.

C++'s protection mechanism (public/private/protected, with friendship)
obviously isn't the most general way to handle things.  Other
languages have different mechanisms, and at least one language,
Eiffel, has one that's much more general.  In C++ there's no good way
for a class to grant access to a single private member function
without granting access to all private members, but in Eiffel it's
easy.  But my (now rather old) experience with Eiffel is that this
feature is rarely used in its full generality.  Most new languages
stick with something like C++'s categories, because, coarse as they
are, they're the categories that turn out to be used in real programs.

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

May be it just funny question.

The friend makes that a function or class can access to
invisible memebers with particular right. It works well for
operator <<, >>, etc.

In this point, the question arises. Why there is no enemy relation.
Enermy relation means that a class or a function even can not see
the public member of a enermy class if they are tied with enermy
relation.

For example,

    class X;
    class Y;

    class X
    {
        enermy class Y;

        public:
            X ( Y & ); // Ok: Y is normal relation class.
    };

    class Y
    {
        public:
            Y( X & ) // Error: X designates the Y to enermy.
    };


I thinks that this kinds of relation are easily arised in real situation.

Is there already consideration occured? If not, why this relation
dose not considered in the Standard or...

Any comments. Thanks.

--
S Kim <stkim@yujinrobot.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                       ]

Kim, Seungtai wrote:
> May be it just funny question.
>
> The friend makes that a function or class can access to
> invisible memebers with particular right. It works well for
> operator <<, >>, etc.
>
> In this point, the question arises. Why there is no enemy relation.
> Enermy relation means that a class or a function even can not see
> the public member of a enermy class if they are tied with enermy
> relation.
>
> [...]
> I thinks that this kinds of relation are easily arised in real situation.

Have you encountered anything _in the real life_ that would be resolved
by introducing the "enemy" specifier?  I haven't.

> Is there already consideration occured? If not, why this relation
> dose not considered in the Standard or...

Because it's not needed, probably.

V

---
[ 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 Thu, 26 Aug 2004 19:26:13 GMT, stkim@yujinrobot.com ("Kim,
Seungtai") wrote:

>May be it just funny question.
>
>The friend makes that a function or class can access to
>invisible memebers with particular right. It works well for
>operator <<, >>, etc.
>
>In this point, the question arises. Why there is no enemy relation.

This ("enemy") is actually the correct spelling, not "enermy".

>Enermy relation means that a class or a function even can not see
>the public member of a enermy class if they are tied with enermy
>relation.
>
>For example,
>
>    class X;
>    class Y;
>
>    class X
>    {
>        enermy class Y;
>
>        public:
>            X ( Y & ); // Ok: Y is normal relation class.
>    };
>
>    class Y
>    {
>        public:
>            Y( X & ) // Error: X designates the Y to enermy.
>    };
>
>
>I thinks that this kinds of relation are easily arised in real situation.
>
>Is there already consideration occured? If not, why this relation
>dose not considered in the Standard or...
>
>Any comments. Thanks.

I think "public" should really mean "available for everyone". Limiting
access to class members can be done by other means, for example making
all members private and listing only those classes as friends which
are allowed to access the data. Or you can use a common base class and
make the otherwise "public" members "protected". Or using anonymous
namespaces, nested classes, etc.

Once something is declared "public", however, there is no turning
back. And I believe it is a good thing because it makes you think
about your classes' designs a bit more.

(just IMHO)

--
Bob Hairgrove
NoSpamPlease@Home.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                       ]

Victor Bazarov wrote:

> Kim, Seungtai wrote:
> Have you encountered anything _in the real life_ that would be resolved
> by introducing the "enemy" specifier?  I haven't.

    There's a related situation where something similar might be
relevant.

    C++ allows member functions of a class to access the private
members of ANY objects of the class they can reach.  This allows copy
constructors, "swap", and similar functions.  But it's unusual
for a class to need to access private members of another object
of the same class.  There's no way to turn that access off,
though.  Perhaps there should be.

    The reason this matters is because it's a synchronization issue.
If a class locks the "this" object on entrance to a public
function member and unlocks it on exit, that protects
the "this" object.  It doesn't protect any other object
the member function can access and mess with.

    If C++ were to address class-level synchronization, as
Java does, this is an issue that should be addressed
at that time.

    John Nagle
    Animats


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

"Victor Bazarov"
> > I thinks that this kinds of relation are easily arised in real situation.
>
> Have you encountered anything _in the real life_ that would be resolved
> by introducing the "enemy" specifier?  I haven't.

Representative example. Bush president of America and
Hussein ex-president of Iraq are enermy relation both of Bush to Hussein
and Hussein to Bush.  In the starcraft(I beleive most of people know
about the game), you can select a party. Only members can only see
the any movements of the others in the same party.

I think still that the enermy relations are existed in many places.

> > Is there already consideration occured? If not, why this relation
> > dose not considered in the Standard or...
>
> Because it's not needed, probably.

Thanks. :-)

--
S Kim <stkim@yujinrobot.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                       ]

"Kim, Seungtai" <stkim@yujinrobot.com> wrote...
> "Victor Bazarov"
> > > I thinks that this kinds of relation are easily arised in real
situation.
> >
> > Have you encountered anything _in the real life_ that would be resolved
> > by introducing the "enemy" specifier?  I haven't.
>
> Representative example. Bush president of America and


I didn't mean your _real life_ outside your programming activities.

> Hussein ex-president of Iraq are enermy relation both of Bush to Hussein
> and Hussein to Bush.  In the starcraft(I beleive most of people know
> about the game), you can select a party. Only members can only see
> the any movements of the others in the same party.

OK, let's imagine that you are actually working on programming that
situation in C++.  I have a question then, how can't it be solved using
current access specifiers?  Declare members of the "same party" friends
to each other, nobody else is going to see "any movements".  Is there
something in the language that prevents you from doing what you need?

> I think still that the enermy relations are existed in many places.

They do.  Just not in programming languages.

V

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

""Victor Bazarov"" <v.Abazarov@comAcast.net> wrote in message
news:kAzXc.52507$9d6.50035@attbi_s54...
> "Kim, Seungtai" <stkim@yujinrobot.com> wrote...
> > "Victor Bazarov"

> > > Have you encountered anything _in the real life_ that would be resolved
> > > by introducing the "enemy" specifier?  I haven't.
> >
> > Representative example. Bush president of America and

> I didn't mean your _real life_ outside your programming activities.

Life outside of programming? I'm not sure I understand. ;-)

> > I think still that the enermy relations are existed in many places.
>
> They do.  Just not in programming languages.

I think the real reason that an enemy relation would be of no use is that it
would be so easily circumvented. The enemy could simply access the public
members of the forbidden class through a thin wrapper. If you try to make the
enemy relation more strict, e.g. by saying that the enemy cannot access any
class or function which is not also an enemy, then the enemy would not even be
able to use std::string. If you say instead that the enemy can not use any
function which indirectly accesses the public members of the forbidden class,
then separate compilation is a problem.

Jonathan


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

"Bob Hairgrove"
> This ("enemy") is actually the correct spelling, not "enermy".

Thanks for correction. My mis-spelling.

> I think "public" should really mean "available for everyone".

Yes. And I assert that the mean "avaliable for everyone" can be
easily extented to "available for everone except enemy".

> Limiting
> access to class members can be done by other means, for example making
> all members private and listing only those classes as friends which
> are allowed to access the data.

But, it may be hard to limit a few classes or functions in a extreamly
large scale project. Don't you ever see that the project has thousands
classes and functions?

> Or you can use a common base class and
> make the otherwise "public" members "protected".

I think that it is another subject. Why do you thinks that it can be
the solution in the situation?

> Or using anonymous namespaces,

Scope problem is arised. Only classes in same translation unit can
access them.

> nested classes, etc.

Nested class dose not mean the relation. Never it can represent
the relation.

> Once something is declared "public", however, there is no turning
> back.

So, IMHO, why it can not be? It can provide new notion to our
logical design issus.

> And I believe it is a good thing because it makes you think
> about your classes' designs a bit more.

Thanks for your opinion.

--
S Kim <stkim@yujinrobot.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                       ]

Kim, Seungtai wrote:
> May be it just funny question.
>
> The friend makes that a function or class can access to
> invisible memebers with particular right. It works well for
> operator <<, >>, etc.
>
> In this point, the question arises. Why there is no enemy relation.
> Enermy relation means that a class or a function even can not see
> the public member of a enermy class if they are tied with enermy
> relation.
>

I think what you want is information hiding, since you use the word
"invisible".

Access specifiers and friendship do not implement information hiding.
Private class members are not invisible, for example. There merely
cannot be accessed accidently.

If you want to hide information from other parts of the program,
several C++ techniques are available, hinted at by other replies in
this thread.

Occasionally someone asks for a feature to keep parts of a class
hidden from some member functions, or to grant partial friendship. I
think such a desire reflects a program organziation that is not
factored properly. Too much unrelated functionality is crammed into
one class. A set of cooperating classes is probably a better solution.

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

Jonathan Turkanis wrote:

>
> I think the real reason that an enemy relation would be of no use is that it
> would be so easily circumvented. The enemy could simply access the public
> members of the forbidden class through a thin wrapper. [...]
>

The enemy relation can circumvented even more easily than that: just
change the name of the class!

Jokes apart, that is a serious inconvenient. As it is, the enemy
relation is nothing more than an aid to the programmer. It just help you
  to avoid making mistakes in your own classes. Other programmers are
completely unaffected because you don't have any control on the names
used by them. In fact, the enemy relation is not even good at that,
because any mistake in the naming of your classes will probably go
undetected. A false sense of security is even worse than no security at all.

Just my opinion,

Alberto

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