Srinivas Vobilisetti wrote in message <35082F4C.44C3@usa.net>...
>Christopher Eltschka wrote:
>>
>What actually I meant is something
>like the following:
>
>class A {
>};
>
>class B {
>};
>
>class C {
>};
>
>class D {
>};
>
>template <class T> class X {
>
>friend class T = A, B, C;
>
>// [...]
>};
>
>The statement "friend class T = A, B, C;" means class A is friend of
>class X<A>, class B is friend of class X<B> and class C is friend of
>class X<C> but class D is not a friend of class X<D>. It also means
>class A is not a friend of class X<S != A>.
>
>By doing this, template class X knows what all classes have access to
>its private members. Otherwise, template classes will turn out to be a
>maintenance nightmare.

But surely this depends on context.  If I design a class that can take
plugins in the form of a template parameter, and if I follow your policy by
explicitly listing each plugin as a friend, then, in order to add another
plugin, a client would have to modify this list of friends, which is code
that he may not own.  This would certainly lead to a much bigger maintenance
nightmare.

--
Please do not use reply, use danielp@anabasis.com instead.
---
[ 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              ]

Srinivas Vobilisetti <srv@cs.wayne.edu> wrote:
> Daniel Parker wrote:
> >
> > Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>...
> > >>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> writes:
> > >
> > >SV> To prevent back door access to template class's private members. If you
> > >SV> give friendship based on the template parameter, then any class can get
> > >SV> 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.
>
> ARM in section 11.4 says, "Friendship, like all other access, is granted
> by the class - not unilaterally grabbed by the friend".

This argument is utterly without merit and completely irrelevant to the current
thread.  To show why, let me give an actual example of where you might want to
make a template parameter a friend of a template:

template<class Container>
class DefineIterators {
  class iterator {
    friend class Container;
    iterator(const typename Container::iterator_rep&);
    // allow Container to create an iterator from an iterator_rep, but don't
    // allow anyone else to do so

    // represent iterator with an iterator_rep, and define iterator members in
    // terms of operations supported by iterator_rep
  };
  class const_iterator
    friend class Container;
    const_iterator(const typename Container::iterator_rep&);
    // allow Container to create a const_iterator from an iterator_rep but
don't
    // allow anyone else to do so

    // represent iterator with an iterator_rep, and define iterator members in
    // terms of operations supported by iterator_rep
  };
};

Christopher Eltschka wrote:
>
> Srinivas Vobilisetti wrote:
> >
> > Daniel Parker wrote:
> > >
> > > Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>...
> > > >>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> 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 <Template-Param>, you have Y is friend of X<Y>
> and Z is friend of X<Z>, but *not* Y is friend of X<Z>.
>
> Also, it *doesn't* open any back door. To get to the private
> members of X<Y>, I can't define another class Z, instantiate an X<Z>,
> and thus access X<Y>'s private data. I can, of course, access the
> private members of X<Y> 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:
>

I did not put it correctly, when I said "List all the classes as friends
in the template class definition". What actually I meant is something
like the following:

class A {
};

class B {
};

class C {
};

class D {
};

template <class T> class X {

friend class T = A, B, C;

// [...]
};

The statement "friend class T = A, B, C;" means class A is friend of
class X<A>, class B is friend of class X<B> and class C is friend of
class X<C> but class D is not a friend of class X<D>. It also means
class A is not a friend of class X<S != A>.

By doing this, template class X knows what all classes have access to
its private members. Otherwise, template classes will turn out to be a
maintenance nightmare.

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

Srinivas Vobilisetti wrote:
>
> Christopher Eltschka wrote:
> >
> > Srinivas Vobilisetti wrote:
> > >
> > > Daniel Parker wrote:
> > > >
> > > > Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>...
> > > > >>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> 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 <Template-Param>, you have Y is friend of X<Y>
> > and Z is friend of X<Z>, but *not* Y is friend of X<Z>.
> >
> > Also, it *doesn't* open any back door. To get to the private
> > members of X<Y>, I can't define another class Z, instantiate an X<Z>,
> > and thus access X<Y>'s private data. I can, of course, access the
> > private members of X<Y> 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:
> >
>
> I did not put it correctly, when I said "List all the classes as friends
> in the template class definition". What actually I meant is something
> like the following:
>
> class A {
> };
>
> class B {
> };
>
> class C {
> };
>
> class D {
> };
>
> template <class T> class X {
>
> friend class T = A, B, C;
>
> // [...]
> };
>
> The statement "friend class T = A, B, C;" means class A is friend of
> class X<A>, class B is friend of class X<B> and class C is friend of
> class X<C> but class D is not a friend of class X<D>. It also means
> class A is not a friend of class X<S != A>.
>
> By doing this, template class X knows what all classes have access to
> its private members. Otherwise, template classes will turn out to be a
> maintenance nightmare.

But by doing this (is this really legal syntax?), you just
pervert the meaning of templates. A template is, well, a template,
from which you can get several classes with the same code (unless
specialized). Your template class indeed encloses three
specialisations: One for X<A>, one for X<B> and one for X<C>.
In effect, it may be absolutely useless for instantiation for
*any* other class (there's obviously a reason why there's a friend
declaration). Therefore you most probably don't have a full-blown
template, but a "restricted" template that is only useful for just
those three classes.

Also note that there is *not* a thing like a "template class"
(although this term is used often), but rather a class template.
That is, the template itself is not a class, and therefore
does not grant friendship to anyone. However, the instatiations
of the template are classes, each independant of the other.
And if the template has a friend declaration for a template
parameter, that means that a generated class should have a friend
declaration to the class specified on instantiation.

You didn't answer the last sentence of my post (which is indeed
the most important one to decide if you are right or not):

---8<---
Then please post an example of accidental misuse of such a friend
declaration for a template parameter.
---8<---
---
[ 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              ]

Christopher Eltschka wrote:
>
>
> You didn't answer the last sentence of my post (which is indeed
> the most important one to decide if you are right or not):
>
> ---8<---
> Then please post an example of accidental misuse of such a friend
> declaration for a template parameter.
> ---8<---
> ---

Sorry, I take my word back about accidental misuse.

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

Christopher Eltschka wrote:
>
<snip>
> But by doing this (is this really legal syntax?),

No. I am just using that syntax to convey my message.

> you just
> pervert the meaning of templates. A template is, well, a template,
> from which you can get several classes with the same code (unless
> specialized). Your template class indeed encloses three
> specialisations: One for X<A>, one for X<B> and one for X<C>.
> In effect, it may be absolutely useless for instantiation for
> *any* other class (there's obviously a reason why there's a friend
> declaration). Therefore you most probably don't have a full-blown
> template, but a "restricted" template that is only useful for just
> those three classes.

As you pointed out, the syntax I showed is not a legal C++
statement/declaration. The following hypothetical class template
definition

template <class T> class X {

friend class T = A, B, C;

// ...
};

means that class A is a friend of X<A>, class B is a friend of X<B>,
class C is a friend of X<C> and class D is NOT a friend of X<D>. But
you can still create an  instantiation X<D>. So, it boils down to
something like

class A { /* ... */ };
class B { /* ... */ };
class C { /* ... */ };
class D { /* ... */ };

class X_A { friend class A; /* ... */ };
class X_B { friend class B; /* ... */ };
class X_C { friend class C; /* ... */ };
class X_D { /* ... */ }; // class D is NOT a friend of class X<D>.

> Also note that there is *not* a thing like a "template class"
> (although this term is used often), but rather a class template.
> That is, the template itself is not a class, and therefore
> does not grant friendship to anyone. However, the instatiations
> of the template are classes, each independant of the other.
> And if the template has a friend declaration for a template
> parameter, that means that a generated class should have a friend
> declaration to the class specified on instantiation.

The issues I am concerned about are:

1. friendship exposes a class's implementation to its friend.
2. The designer thinks in terms of the class template but not in terms
of each individual instantiation of the class template.

The reason I am not in favor of friendship to a template parameter
is that the class template has NO idea what all classes have access to
its private data. By which I mean, any class T, for which an
instantiation X<T> exists, can make assumptions about the implementation
details of the class X<T>. But the designer develops (or codes) class
template X but not the instantiation X<T>. The compiler generates class
instantiation X<T>. So, if the designer of the class template wants to
change its implementation, he can not dare do it because he forgoes the
concept of Data Abstraction at the class template level.

> You didn't answer the last sentence of my post (which is indeed
> the most important one to decide if you are right or not):
>
> ---8<---
> Then please post an example of accidental misuse of such a friend
> declaration for a template parameter.
> ---8<---

I did not use the term 'accidental misuse' for "friend declaration for a
template parameter". The post to which I replied says,

-------Pasted from another post-----------
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.
-------Pasted from another post-----------


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

Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>...
>>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> writes:
>
>SV> To prevent back door access to template class's private members. If you
>SV> give friendship based on the template parameter, then any class can get
>SV> access to the template private members thru back door
>
>"Back door"??? What is the front door then? 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!

I agree wholeheartedly with this post; the justification stated above is,
quite frankly, nuts.  What it means is that the developer is compelled to
make a data member public that he'd rather not, which is bad.  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.

Regards,
Daniel Parker

--
Please do not use reply, use danielp@anabasis.com instead.
---
[ 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              ]

Daniel Parker wrote:
>
> Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>...
> >>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> writes:
> >
> >SV> To prevent back door access to template class's private members. If you
> >SV> give friendship based on the template parameter, then any class can get
> >SV> 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.

ARM in section 11.4 says, "Friendship, like all other access, is granted
by the class - not unilaterally grabbed by the friend".

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

> I agree wholeheartedly with this post; the justification stated above is,
> quite frankly, nuts.

What is nuts in it?

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

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

>
> Regards,
> Daniel Parker
>

Regards,
Srinivas
---
[ 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              ]

Isn't this one of those chicken-and-egg kind of things?  Consider
this code:

template<class T> class X { ... };

class A { X<A> xa; // error! can only use refs./ptrs to A
};                 // before done declaring A

If the parameter T is a friend of X<T>, wouldn't this lead to a
forward reference like the one above?  I guess you could only
refer to X<A> in non-inline member functions.  That's getting
into some pretty fine distinctions though.


Jaakko =?UNKNOWN-8BIT?Q?J=E4rvi?= wrote:
>
> Hi,
>
> Why is this ill-formed?
>
> template<class T> class X { friend class T; ...
>
> It is clearly stated in the standard (below a clip from CD2), but what is
> the reason behind it.
>
> /Jaakko
>
>  7.1.5.3  Elaborated type specifiers                    [dcl.type.elab]
> ...
> 2 ...
>   If the identifier (my addition: in friend class identifier) resolves to a
> typedef-name or a tem-
>   plate  type-parameter,  the  elaborated-type-specifier  is ill-formed.
>   [Note: this implies that, within a  class  template  with  a  template
>   type-parameter T, the declaration          friend class T;
>   is  ill-formed.  ]
>
---
[ 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              ]

Srinivas Vobilisetti wrote:
>
> Daniel Parker wrote:
> >
> > Marc Girod wrote in message <1yiuppeaon.fsf@dshp01.ntc.nokia.com>...
> > >>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> 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 <Template-Param>, you have Y is friend of X<Y>
and Z is friend of X<Z>, but *not* Y is friend of X<Z>.

Also, it *doesn't* open any back door. To get to the private
members of X<Y>, I can't define another class Z, instantiate an X<Z>,
and thus access X<Y>'s private data. I can, of course, access the
private members of X<Y> 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<class T> void f(T&) const;
};

Now I do

class Backdoor { public: int* value };

template<> void X::f<Backdoor>(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<Y> grants friendship specifically to Y.
Recall that X<Y> and X<Z> 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<class T> friend class T;
// ...
};

but we are discussing the case

template<class T> 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<Y> grants
friendship specifically to class Y, and the (completely unrelated)
class X<Z> 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              ]

Srinivas Vobilisetti wrote:
>
> Jaakko =?UNKNOWN-8BIT?Q?J=E4rvi?= wrote:
> >
> > Hi,
> >
> > Why is this ill-formed?
> >
> > template<class T> class X { friend class T; ...
> >
> > It is clearly stated in the standard (below a clip from CD2), but what is
> > the reason behind it.
> >
> > /Jaakko
> >
> >  7.1.5.3  Elaborated type specifiers                    [dcl.type.elab]
> > ...
> > 2 ...
> >   If the identifier (my addition: in friend class identifier) resolves to a
> > typedef-name or a tem-
> >   plate  type-parameter,  the  elaborated-type-specifier  is ill-formed.
> >   [Note: this implies that, within a  class  template  with  a  template
> >   type-parameter T, the declaration          friend class T;
> >   is  ill-formed.  ]
> >
>
> To prevent back door access to template class's private members. If you
> give friendship based on the template parameter, then any class can get
> access to the template private members thru back door (by creating an
> instance of the template with its type as parameter). Taking your
> example, my class Y can get access to private members of your template
> class X by creating an instance of X<Y>.

You're missing a key point here: only one class can get access to the
private members of X<Classname>, and that is 'Classname'. X<MyClass> is
a different class than X<YourClass>. Instantiating X<YourClass> cannot
give you any YourClass access to the private members of X<MyClass>.

There may be good reasons for this restriction, but this isn't one of
them.
---
[ 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              ]

Hi,

Why is this ill-formed?

template<class T> class X { friend class T; ...

It is clearly stated in the standard (below a clip from CD2), but what is
the reason behind it.

/Jaakko

 7.1.5.3  Elaborated type specifiers                    [dcl.type.elab]
...
2 ...
  If the identifier (my addition: in friend class identifier) resolves to a
typedef-name or a tem-
  plate  type-parameter,  the  elaborated-type-specifier  is ill-formed.
  [Note: this implies that, within a  class  template  with  a  template
  type-parameter T, the declaration          friend class T;
  is  ill-formed.  ]

--
< Jaakko J   rvi, Computer Science, University of Turku, Finland >
< Email: jjarvi@cs.utu.fi
>
---
[ 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              ]

Jaakko =?UNKNOWN-8BIT?Q?J=E4rvi?= wrote:
>
> Hi,
>
> Why is this ill-formed?
>
> template<class T> class X { friend class T; ...
>
> It is clearly stated in the standard (below a clip from CD2), but what is
> the reason behind it.
>
> /Jaakko
>
>  7.1.5.3  Elaborated type specifiers                    [dcl.type.elab]
> ...
> 2 ...
>   If the identifier (my addition: in friend class identifier) resolves to a
> typedef-name or a tem-
>   plate  type-parameter,  the  elaborated-type-specifier  is ill-formed.
>   [Note: this implies that, within a  class  template  with  a  template
>   type-parameter T, the declaration          friend class T;
>   is  ill-formed.  ]
>

To prevent back door access to template class's private members. If you
give friendship based on the template parameter, then any class can get
access to the template private members thru back door (by creating an
instance of the template with its type as parameter). Taking your
example, my class Y can get access to private members of your template
class X by creating an instance of X<Y>.

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

>>>>> "SV" == Srinivas Vobilisetti <srv@cs.wayne.edu> writes:

SV> To prevent back door access to template class's private members. If you
SV> give friendship based on the template parameter, then any class can get
SV> access to the template private members thru back door

"Back door"??? What is the front door then? 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!

Such a religious statement cannot be the reason for what looks like a
gratuitous break of orthogonality (you first write your code so that
you have a plain class, then you notice that you can abstract some
bits into a template, and the whole thing breaks down...). There must
have been some implementation or undecidability (or fear thereof)
problems...

Best Regards!

--
Marc Girod         Nokia Telecommunications  NWS/NMS/NMD/NOMA
Valimo 1/2         P.O. Box 315              Phone:  +358-9-511 63331
00380 Helsinki     00045 NOKIA Group         Fax:    +358-9-511 63310
Finland                                      marc.girod@ntc.nokia.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              ]