From 2536619412532795912 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,5e0145d162a6d1d6 X-Google-Attributes: gidf78e5,public From: Christopher Eltschka Subject: Re: Why is granting friendship to a templ. parameter ill-formed? Date: 1998/03/11 Message-ID: <35069238.1C1DAA80@physik.tu-muenchen.de>#1/1 X-Deja-AN: 333023352 Content-Transfer-Encoding: 7bit References: <6dop9s$kq6$1@news.utu.fi> <35005B2A.7410@cs.wayne.edu> <1yiuppeaon.fsf@dshp01.ntc.nokia.com> <6e2i9u$rig$1@news.interlog.com> <350587D6.3EA6@cs.wayne.edu> X-Original-Date: Wed, 11 Mar 1998 14:31:36 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany) X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANQa+g+EDnX0m9pzZAQHVFwF9FFQlhYwKH5BFOLperpTSeWvcG677V1xU nzOzu4X+cBZwfdooezbt9lW4KBQ5jVNn =sJ6P Newsgroups: comp.std.c++ Srinivas Vobilisetti wrote: > > Daniel Parker wrote: > > > > Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>... > > >>>>>> "SV" == Srinivas Vobilisetti writes: > > > > > >SV> To prevent back door access to template class's private members. > > >SV> If you give friendship based on the template parameter, then any > > >SV> class can get access to the template private members thru back door > > > > > >"Back door"??? What is the front door then? > > Front door? List all the classes as friends in the template class > definition. But that is not quite the same: With friend class , you have Y is friend of X and Z is friend of X, but *not* Y is friend of X. Also, it *doesn't* open any back door. To get to the private members of X, I can't define another class Z, instantiate an X, and thus access X's private data. I can, of course, access the private members of X from Y - but that's what the friend declaration is for, and the reason to put it there in the first place (nobody puts it there because it just looks cool). If a template parameter is declared friend, it is obviously thought as working together with that class. What *does* open a back door to the template class members are templated member functions (which are indeed allowed). For example: class X { int a; public: template void f(T&) const; }; Now I do class Backdoor { public: int* value }; template<> void X::f(Backdoor& b) // I hope I got the syntax right { b.value=&a; } Summary: Declaring a template parameter a friend doesn't open a backdoor. OTOH, even if it would do so, there are other constructs (template member functions), which make a backdoor wide open. > ARM in section 11.4 says, "Friendship, like all other access, is granted > by the class - not unilaterally grabbed by the friend". And in this case, the class X grants friendship specifically to Y. Recall that X and X are completely unrelated classes. > ARM also says (about overloaded functions), "One could imagine declaring > all functions called f friends by a single declaration, but doing so > would be a bit indiscriminate. It would enable a user to grab access to > a class simply by declaring a function f with a hitherto unused argument > type." This is a completely different situation. For classes, it would be like class X { template friend class T; // ... }; but we are discussing the case template class X { friend class T; // .. }; > > >This would only be > > >clear and explicit. It could be the only access. I know I lack it > > >badly, and where I do, I have to make the access public and put > > >dynamic guards: a shame! > > Granting friendship access to a template parameter violates > encapsulation. Probably, you need to change your design. No more than every other friendship does. Especially class X grants friendship specifically to class Y, and the (completely unrelated) class X grants friendship specifically to class Z. It's the same as class XY { friend class Y; // ... }; class Y { // ... }; class XZ { friend class Z; // ... }; class Z { // ... }; Now, where do you see a backdoor in this design? > > I agree wholeheartedly with this post; the justification stated above is, > > quite frankly, nuts. > > What is nuts in it? That it's plain wrong. There's no backdoor at all. The only way to create a backdoor are member templates (which are explicitly allowed). > >What it means is that the developer is compelled to > > make a data member public that he'd rather not, which is bad. > > No. what it means is that the developer should rethink about his design. There's nothing evil with it. > >If the intent > > of the standard was to prevent the client from discovering a way of misusing > > a class, I have some very bad news: in C++ it is always possible for the > > client to misue a class. That's a non-issue, utterly beside the point. > > The intent of of the standard was to prevent accidental misuse of a > class but not intentional misuse. Then please post an example of accidental misuse of such a friend declaration for a template parameter. --- [ 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 ]