Re: Private Member Access failed through Friend function
{ Article edited: quoted signature and clc++m banner removed. Tip: a
good Usenet client program will do that automatically for you. -mod }
On May 3, 8:06 am, Seungbeom Kim <musip...@bawi.org> wrote:
Cumhur Guzel wrote:
{ Quoted banner & signature removed. Note: most Usenet client programs
will do that automatically for you (hint hint). -mod }
On Apr 30, 7:12 pm, Seungbeom Kim <musip...@bawi.org> wrote:
I agree, but I'd also like to point out a situation where defining a
separate print() function would be useful: polymorphic classes. Because
calls to operator<< cannot be dispatched virtually depending on the
right-hand side operand, defining virtual print() functions and calling
that of the base class in operator<<(std::ostream&, const Base&) is
almost "the" right answer.
I think you could get better encapsulation plus flexibility by using
the template method pattern with NVI,
as given below. As far as I remember, something similar to given below
is suggested in Meyer's Effective C++
or More Effective C++;
Can you elaborate on "better encapsulation plus flexibility" we can get
here?
class Base
{
public:
void print(std::ostream& os)
{
myprint(os);
};
private:
virtual void myprint(std::ostream&)=0;
};
It's basically the same idea; the non-virtual interface pattern you
showed is something to add on top of the "virtual member + non-member
operator<<" pattern, not a replacement of it. The basic idea that the
non-member operator<< calls a virtual member remains the same.
Furthermore, the purpose of the NVI pattern is to enforce some pre-
and/or post-condition to the virtual functions. Since there's no
additional conditions to enforce in your print function (and it's not
very likely that you'll have any in the future), there's little point in
having a separate non-virtual member that calls the virtual member.
Still, we could consider my example as a variation of the NVI pattern,
for a different purpose: to provide a different syntax (os << obj
instead of obj.print(os)). The non-member operator<< here serves as the
non-virtual interface in the NVI pattern. (For a complete analogy, you
could make the virtual member private and make the non-member a friend.)
What I propose is not a huge gain in encapsulation when you compare
against friend function plus NVI solution. However, it is better than
public function interface implemention.
Flexibility comes from the template method pattern. Class's public
interface
is exposed through base class print function and private virtual
myprint custom functions can be changed as it required
in derived classes.
However, I am going to propose something different which may be close
to what you propose.
namespace Z
{
template<class T>
std::ostream& operator<<(std::ostream& os, T& t)
{
t.print(os);
return os;
};
class Type1
{
private:
friend std::ostream& operator<< <> (std::ostream& os, Type1& t);
// friend std::ostream& operator<<
(std::ostream& os, Type1& t); //this could also work
void print(std::ostream& os){};
};
class Type2
{
private:
void print(std::ostream& os){};
friend std::ostream& operator<< <> (std::ostream& os, Type2& t);
//friend std::ostream& operator<<
(std::ostream& os, Type2& t);
};
void f()
{
Type1 type1;
Type1 type2;
std::cout<<type1;
std::cout<<type2;
};
};
I think this way you can achieve high level of encapsulation and
generic implementation provide
genericity for any class implementing print function nonvirtually.
The downside could be definition burden of friend template operator
functions in the classes.
Cumhur Guzel
Integrated Research Ltd.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]