打印课程 [英] Printing a class

问题描述

如果我有一些Foo类，我打印它的标准方法就是超载

operator<<作为朋友，例如，


class Foo {

int i;

public：

Foo（）：我（0）{}

朋友std :: ostream& operator<<（std :: ostream& o，const Foo& f）;

};


但是，我看到有人提供单独的公开print（）方法，

然后只是从运算符中调用它<<：


class Foo {

int i;

public：

Foo（）：i（0）{}

void print（std :: ostream& o）;

};


std :: ostream& operator<<（std :: ostream& o，const Foo& f）

{

f.print（o）;

return o;

}


是否有任何技术上的理由说明为什么这个方法应优先于朋友运营商<<<<<假设我完全控制了Foo？


-

Marcus Kwok

将''无效'替换为'' net''回复

解决方案

2月19日上午10：23，ricec ... @ gehennom.invalid（Marcus Kwok）写道：

如果我有一些类Foo，我打印它的标准方法是超载

operator<<作为朋友，例如，


class Foo {

int i;

public：

Foo（）：我（0）{}

朋友std :: ostream& operator<<（std :: ostream& o，const Foo& f）;

};


但是，我看到有人提供单独的公开print（）方法，

然后只是从运算符中调用它<<：


class Foo {

int i;

public：

Foo（）：i（0）{}

void print（std :: ostream& o）;

};


std :: ostream& operator<<（std :: ostream& o，const Foo& f）

{

f.print（o）;

return o;

}


是否有任何技术上的理由说明为什么这个方法应优先于朋友运营商<<<<<假设我完全控制了Foo？


-

Marcus Kwok

将''无效'替换为'' net''回复

为了约定，朋友的功能是不道德的劝阻

，因为它们打破了真正的封装。在我看来，朋友的功能已经感觉像是一个黑客。这并不是说有合适的方式来使用友元函数（以及重写<<<<<<<<<<<<<<<<<<<<<<<<<<<<如果可能。使用

print（）作为类方法维护类封装。


j0rd4n

< blockquote> 2月19日16:23，ricec ... @ gehennom.invalid（Marcus Kwok）写道：

如果我有一些类Foo，我的标准方式用于打印的是超载

operator<<作为朋友，例如，


class Foo {

int i;

public：

Foo（）：我（0）{}

朋友std :: ostream& operator<<（std :: ostream& o，const Foo& f）;

};


但是，我看到有人提供单独的公开print（）方法，

然后只是从运算符中调用它<<：


class Foo {

int i;

public：

Foo（）：i（0）{}

void print（std :: ostream& o）;

};


std :: ostream& operator<<（std :: ostream& o，const Foo& f）

{

f.print（o）;

return o;

}


是否有任何技术上的理由说明为什么这个方法应优先于朋友运营商<<<<<假设我完全控制了Foo？

我看不出打印功能有什么好处。它增加了另一个

的间接层，没有任何收益，只是为了它而不是朋友。只是这样做以避免使用朋友对我来说没有任何意义。朋友是代码味道。这意味着每当你发现自己使用它时，你应该考虑你的设计是否正确。

但是说每次我想要都是完全不同的

使用朋友，我会盲目地重构代码，直到

的朋友已经离开了。一般来说，考虑朋友是否真的是* b $ b *是最好的设计，并准备接受amswer可能

是是。


在这种情况下，我认为答案是肯定的。它是一个相当着名的

惯用语，因为运算符<<不能成为会员而且

替代方案在任何方面都不是优越的。


如果您决定使用打印成员函数那么它应该是
可能是一个const成员函数。


Gavin Deane

j0rd4n写道：

2月19日上午10：23，ricec ... @ gehennom.invalid（Marcus Kwok）写道：

>如果我有一些类Foo，我打印它的标准方法是重载
运算符<<作为朋友，例如，类Foo {
int i;
公开：
Foo（）：我（0）{}
朋友std :: ostream的和放; operator<<（std :: ostream& o，const Foo& f）;
};

但是，我看到人们提供了一个单独的公共print（）方法，然后只是从运营商那里调用它<<：

类Foo {
int i;
公共：
Foo（）：i（0）{}
void print（std :: ostream& o）;
};

std :: ostream& operator<<（std :: ostream& o，const Foo& f）
{
f.print（o）;
return o;
}
<有没有任何技术上的理由为什么这个方法应该优先于朋友操作员<<，假设我完全控制了Foo？

-
Marcus Kwok
用''net''替换''invalid''以回复

为了约定，朋友的功能是不道德的劝阻

根据您店铺/社区

的本地风格/编码风格，可能不鼓励他们。但是，这几乎不是一般性建议。

因为它们打破了真正的封装。

这种理性充其量是误导性的：C ++采用的方法是通过指定对象表达式的含义来定义一个类

的接口

是其中的一部分（例如，这最好地解释了运算符重载）。特别是，将对象作为参数的
非成员函数是类

接口的一部分。朋友声明为非成员做了什么访问说明符

（公共，私人，受保护）为成员做的事。

在我看来朋友的功能

总觉得自己像个黑客。这并不是说有合适的方式来使用友元函数（以及重写<<<<<<<<<<<<<<<<<<<<<<<<<<<<如果可能。

将OO编程置于其他编程风格之上是一个可能对您的商店/社区有意义的决定

。但是，确实没有从那里概括出来。一个人应该选择哪种编程风格

取决于当前的问题，甚至更多，取决于当地文化;

程序旨在将意图传达给其他人程序员，所以你的同龄人的阅读习惯和他们的期望会严重影响

对你来说是个好习惯。这可能意味着你的大多数代码结束了OO，但它也意味着你所有代码的最终结果都是使用通用编程或基于策略的大量模板设计。

使用print（）作为类方法维护类封装。

没有比朋友运营商更好的<<。这就是Stroustrup必须说的关于朋友和封装的
：

http://www.research.att.com/~bs/bs_faq2.html#friend


Best


Kai-Uwe Bux

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std::ostream& operator<<(std::ostream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std::ostream& o);
};

std::ostream& operator<<(std::ostream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

--
Marcus Kwok
Replace ''invalid'' with ''net'' to reply

解决方案

On Feb 19, 10:23 am, [e-mail] (Marcus Kwok) wrote:

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std::ostream& operator<<(std::ostream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std::ostream& o);
};

std::ostream& operator<<(std::ostream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

--
Marcus Kwok
Replace ''invalid'' with ''net'' to reply

For the sake of convention, friend functions are tyically discouraged
as they break true encapsulation. In my opinion friend functions have
always felt like a hack. That is not to say there are appropriate
ways to use friend functions (and necessary times like overriding <<),
but it is always best to use OOP paradigms when possible. Using
print() as a class method maintains class encapsulation.

j0rd4n

On 19 Feb, 16:23, [e-mail] (Marcus Kwok) wrote:

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std::ostream& operator<<(std::ostream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std::ostream& o);
};

std::ostream& operator<<(std::ostream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

I can''t see any great benefit in the print function. It adds another
layer of indirection for no gain, avoiding the friend just for the
sake of it. Just doing it to avoid having to use a friend makes no
sense to me. friend is a code smell. That means that whenever you find
yourself using it, you should consider whether your design is correct.
But that is a completely different thing to saying "every time I want
to use a friend, I will mindlessly restructure the code until the
friend has gone away". In general, consider whether the friend really
*is* the best design and be prepared to accept that the amswer might
be "yes".

In this case I think the answer is yes. It''s a fairly well known
idiom, necessary because operator<< can''t be a member and the
alternative isn''t superior in any way.

If you do decide to go with a print member function then it should
probably be a const member function.

Gavin Deane

j0rd4n wrote:

On Feb 19, 10:23 am, [e-mail] (Marcus Kwok) wrote:

>If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std::ostream& operator<<(std::ostream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std::ostream& o);
};

std::ostream& operator<<(std::ostream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

--
Marcus Kwok
Replace ''invalid'' with ''net'' to reply

For the sake of convention, friend functions are tyically discouraged

Maybe they are discouraged according to the local style/coding styles in
your shop/community. However, that is hardly a general recommendation.

as they break true encapsulation.

And this rational is misleading at best: C++ takes the approach that a class
defines its interface by specifying the meaning of expressions that objects
are part of (e.g., this best explains operator overloading). In particular,
non-member functions that take objects as parameters are part of the class
interface. Friend declarations do for non-members what access specifiers
(public, private, protected) do for members.

In my opinion friend functions have
always felt like a hack. That is not to say there are appropriate
ways to use friend functions (and necessary times like overriding <<),
but it is always best to use OOP paradigms when possible.

Putting OO programming above other programming styles is, again, a decision
that may make sense for your shop/community. It does, however, not really
generalize from there. Which programming style one should opt for very much
depends on the problem at hand and, maybe even more, on the local culture;
programs are meant to communicate intent to other programmers, so the
reading habits of your peers and their expectations heavily influence what
would be good practice for you. That can mean that most of your code ends
up being OO, but it can also mean that allmost all your code ends up being
heavily templated employing generic programming or policy based design.

Using print() as a class method maintains class encapsulation.

Not any better than a friend operator<<. This is what Stroustrup has to say
about friends and encapsulation:

http://www.research.att.com/~bs/bs_faq2.html#friend

Best

Kai-Uwe Bux

这篇关于打印课程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！