It's a bit hard to recall my exact need when I have wanted this at this
time, but I know that many times this has annoyed me, and that the
deadline for meaningfully making some proposal is looming large,
however, ... here goes.

template <class T> bool do_something(T& t)
{
  T* firstChild = t.first_child();
  T* lastChild = t.last_child();
  // robble, robble, robble, ...
  return the_robble_robble_robble_worked;
}

class A
{
public:
  A();
  ~A();
  // etc, ...
  bool user_method() { return do_something(*this); }
public: // I want this private, but if I want to do_something, well ...
  A* first_child();
  A* last_child();
};

So if template <class T> bool do_something(T& t), was macro <class T>
bool do_something(T& t), and 'macro' was treated as though its body was
expanded inside of user_method, instead of outside of it as with
'template', then A::first_child() and A::last_child() could be private.

As it stands, any user can have their (robble, robble, robble) way with
my children, and I am powerless to stop 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bruce Mellows" <bruce+101@wakethegimp.org> skrev i meddelandet
news:1123110534.864944.99490@f14g2000cwb.googlegroups.com...
> It's a bit hard to recall my exact need when I have wanted this at
> this
> time, but I know that many times this has annoyed me, and that the
> deadline for meaningfully making some proposal is looming large,
> however, ... here goes.
>
> template <class T> bool do_something(T& t)
> {
>  T* firstChild = t.first_child();
>  T* lastChild = t.last_child();
>  // robble, robble, robble, ...
>  return the_robble_robble_robble_worked;
> }
>
> class A
> {
> public:
>  A();
>  ~A();
>  // etc, ...
>  bool user_method() { return do_something(*this); }
> public: // I want this private, but if I want to do_something, well
> ...
>  A* first_child();
>  A* last_child();
> };
>
> So if template <class T> bool do_something(T& t), was macro <class
> T>
> bool do_something(T& t), and 'macro' was treated as though its body
> was
> expanded inside of user_method, instead of outside of it as with
> 'template', then A::first_child() and A::last_child() could be
> private.
>
> As it stands, any user can have their (robble, robble, robble) way
> with
> my children, and I am powerless to stop them.
>

This is exactly where you would use 'friend' to tell the compiler who
can access class A's internals. That is a decision up to A (or its
implementor), not to someone writing a possibly unrelated macro<>
somewhere else. Why would that macro<> be allowed to declare itself
friend of everybody else in the whole world?!

If you just want it to access the children, the interface should be
do_something(first_child(), last_child()). That way class A can give
out access to its children when A sees fit, not when do_something
feels like it.


Bo Persson


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

This does not actually make the macro anybody's friend, let alone
everybody's friend.

The macro take its priviledge from the function/method that
instantiates it, such that the instantiator could have put those lines
of code in themselves, or worst yet, have just used #define ... to
achieve the result, which is what template was designed to alleviate.

So you see, there is no breaking of priviledge, the priviledge already
exists, its just that the mechanism to reuse code does not allow for
the existing priviledge to be confered.

What I am attempting to acheive here is removing all the friend
declarations and (if you're being smart), all the includes from the
interface declaration, just so that some implimenatation definition can
reuse a peice of code.

I am trying not to burden your implimentation with my implimentation.

And yes, calling do_something(first_child(), last_child()) is totally
the correct way of addressing the case at hand, but this was in fact a
trivial example, because Victor Bazarov asked for one, and that the
bigger picture sometimes precludes this sort of trivial answer.

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

Templates are constrained to access other constructs as first class
constructs themselves.

This can cause a need for a class to expose an interface for the
template to operate upon.

It would be beneficial for another form of template, (perhaps a
macro<>), that operates with the priviledge of the construct that
instantiates it, such that it can be considered a friend of a class
without actually being named as a friend, by being instantiated by a
method of the class.

This can reduce the need for C-style #define macros, and allow
constructs to use template-style functions and classes without having to
provide a specific interface for 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bruce Mellows wrote:
> Templates are constrained to access other constructs as first class
> constructs themselves.
>
> This can cause a need for a class to expose an interface for the
> template to operate upon.
>
> It would be beneficial for another form of template, (perhaps a
> macro<>), that operates with the priviledge of the construct that
> instantiates it, such that it can be considered a friend of a class
> without actually being named as a friend, by being instantiated by a
> method of the class.
>
> This can reduce the need for C-style #define macros, and allow
> constructs to use template-style functions and classes without having to
> provide a specific interface for them.

Could you elaborate a bit?  Post code you'd like to see working (it need
not compile now, since certain mechanisms are allegedly missing).

Thanks.

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                       ]

Bruce Mellows schreef:

> Templates are constrained to access other constructs as first class
> constructs themselves.
>
> This can cause a need for a class to expose an interface for the
> template to operate upon.
>
> It would be beneficial for another form of template, (perhaps a
> macro<>), that operates with the priviledge of the construct that
> instantiates it, such that it can be considered a friend of a class
> without actually being named as a friend, by being instantiated by a
> method of the class.

Did you know that methods (member functions) can be templates too?

HTH,
Michiel Salters

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