要bean还是不要bean [英] To bean or not to bean
问题描述
Stroustrup'对课程的看法，在很大程度上，似乎集中在不变量的概念上。
不变量的概念。在对计算机科学中的yamt（还有另一个数学术语）的使用进行了一些调整之后，我开始欣赏他所声称的一些
意义。我相信一个很好的例子是Riemann-Christoffel曲率张量。在一般相对论的4空间中，这个野兽有256个组成部分。
表示这个张量的一种方法可能是一个256浮点数的结构
成员全部公开。用户只需将其视为一大包。这个
张量 - 根据定义 - 具有某些不变的属性，在某些操作组下必须保持不变。这意味着，如果
直接修改组件，那么
用户必须能够执行保留不变量的规则。出于这个原因，将数据放入类中只允许通过使用
的不变保留访问方法来控制访问是有意义的。
Stroustrup还认为合理的测试来确定你是否确实使用不变量的类来判断是否有多个
表示数据结构在功能上是等价的。
确实存在这种张量。这实际上可以为你买单。
虽然张量有256个组件，但只有20个是独立的。那个
意味着你可以将张量表示为只有20个数据成员的对象，
如果情况要求程序中有所有256个组件，
可以通过多次索引存储位置来实现，通过
访问方法，这些方法总体上给出了整个张量
存在的错觉，其中包含所有256个组件。
到目前为止，非常好。我非常同意他的理由来区分
之间应该恰当地表示为具有私有（或
保护）数据的类，而不是仅仅是一个包含所有数据的结构公众成员和
直接用户访问权限。例如，我喜欢在C ++中发现的许多细致的识别，例如与Java相对的
。在典型的Java文献中，没有constness和
可变缓存的概念。这表明我C ++具有超越其他通用语言的表达能力。
然而，有一点是Stroustrup没有解决的问题
''访问者''方法。他告诉我们，我们应该避免使用
直接存取方法来操纵数据。这个推理似乎对我来说很明显。如果用户有理由对数据进行微观管理，那么它可能没有一个明确定义的不变量，可以而且应该在应用的操作下保留
统一的。
Java社区的运作方式与数据和
类不同。基本上，除了静态常量之外，没有什么是公共的，并且
访问器方法。 Java中最简单的概念只是一个类
，数据成员通过set和get的调解来读写，
方法。这种非常保护性的数据管理方法得到了回报，它促进了诸如事件监听器模式和
并发编程等设计功能。访问方法提供了一种自然的方式来锁定对数据的访问，并且还为了事件的目的监视访问。
通知。
TC ++ PL（SE）中一个更重要的发展是创建
抽象用户界面组件，作为演示使用继承的各种
选项的一种方法和类层次结构。 Stroustrup辩称 -
正确的IMO - 程序员应该努力解决问题
独立于他可能正在开发的专有库。
这就是我一直称之为AUI（抽象用户界面）几年的b
。我决定尝试练习作为项目的一部分我正在工作
on目标是直观地表示各种访问模式使用
来模拟多维数组使用valarray，切片和gslices。
程序创建一个网格单元格对象树，它成为多维矩阵图形表示的元素
。
我创建了一个包含所有纯虚函数的接口类，以及一个数据
成员。数据成员是一个对象，其中包含在不同网格元素之间共享的默认值
。这可能看起来有些错综复杂，但它让我做了一些有趣的事情，比如改变默认值对象的价值，通知所有网格单元对象
拥有一个默认值已经更改的DefaultBox，他们需要
才能考虑更新。
这表明我是什么关于使用
事件/监听器（观察者）模式来适应特定
对象的变化。我的设计似乎也有其他的东西。
用于默认初始化网格单元格的类是一个很好的例子
我'我找到了适合我的设计，这似乎与
Stroustrup建议避免''set''和'get''功能相矛盾。那个'/ b $ b实际上是我的网格单元对象组成的一个非常重要的部分。
也就是说，数据成员具有读取和变异函数的数据。 />
#ifndef STHBOXDEFAULTS_H
#define STHBOXDEFAULTS_H
#include< string>
命名空间sth
{
使用std :: string;
/ **
@author Steven T. Hatton
* /
类BoxDefaults
{
public：
BoxDefaults（bool is_leaf_ = false，
bool is_vertical_ = false，
string text_ =" [...]"，
RgbColor bg_color_ = RgbColor ::黄色，
RgbColor text_color_ = RgbColor :: BLACK，
RgbColor edge_color_ = RgbColor :: RED，
double h_ = 35，
double w_ = 50，
double border_w_ = 5，
double x_ = 0，
double y_ = 0 ，
int bg_z_ = 1，
int text_z_ = 2
）
：is_leaf（is_leaf_），
is_vertical（ is_vertical_），
text（text_），
bg_color（bg_color_），
text_color（text_color_），
edge_color（edge_color_），
h（h_），
w（w_），
border_w（border_w）
{ }
虚拟~BoxDefaults（）{}
/ **
*儿童箱是否垂直摆放？
* /
虚拟布尔Is_vertical（）const
{
返回此 - > is_vertical;
}
虚拟空虚Is_vertical（const bool& is_vertical_）
{
this-> is_vertical = is_vertical_;
}
/ * *
*这是叶节点吗？
* /
虚拟布尔Is_leaf（）const
{
返回此 - > is_leaf;
}
虚拟空虚Is_leaf（const bool& is_leaf_）
{
this-> is_leaf = is_leaf_;
}
虚拟RgbColor Bg_color（）const
{
返回此 - > bg_color;
}
虚拟空白Bg_color（const RgbColor& bg_color_）
{
this-> bg_color = bg_color_;
}
/ *等等* /
};
}
这对我来说似乎很自然，但它让我有点不安，因为
Stroustrup建议它可能不是一个好的设计方法。我不会说他还坚持认为他的建议和意见不是以不可侵犯的指示，也不是所有人都可以平等地适用于所有
情况。
您对使用'Java Bean'设计方法有何看法？我知道，对于Bean来说，还有更多的东西，而不仅仅是一个包含数据，事件和
相关监听器的类。尽管如此，这似乎是他们实际上最终的本质。 JavaBean
规范的某些方面让我感到晦涩，并且似乎提供了比潜在价值更多的潜在麻烦。我相信一般的方法是值得理解的东西，并考虑到C ++设计。这是
JavaBean规范：
http://java.sun.com/products/javabeans/docs/spec.html
您怎么看？这些想法可能适用于C ++代码吗？
-
[M]不喜欢预处理器是众所周知的。 Cpp在C / $
编程中是必不可少的，并且在传统的C ++实现中仍然很重要，但
它是一个hack，大多数依赖它的技术也是如此。 ......我认为
是时候认真对待无宏C ++编程。 - BS
Stroustrup''s view on classes, for the most part, seems to be centered around
the notion of invariants. After a bit of adjusting to the use of yamt (yet
another math term) in computer science, I came to appreciate some of the
significance in what he is asserting. I believe a good example would be
the Riemann-Christoffel curvature tensor. In the 4-space of general
relativity, there are 256 components of this beast.
One approach to representing this tensor might be a struct with 256 float
members all public. The user simply treats it as a big bag of bits. This
tensor - by definition - has certain invariant properties which must remain
constant under certain groups of operations. That means that, either the
user must be carful to enforce the rules preserving the invariants if he is
going to modify the components directly. For this reason, it makes sense
to put the data in a class and only allow controlled access through the use
of invariant preserving access methods.
Stroustrup also argues that a reasonable test to determine if you really do
have a class with invariants is to ask if there are multiple
representations of the data structure which are functionally equivalent.
Indeed there are for this tensor. And that can actually buy you a lot.
Although the tensor has 256 components, only 20 are independent. That
means you can represent the tensor as an object of only 20 data members,
and if circumstances demand all 256 components be available in the program,
that can be accomplished by multiply indexing the storage locations through
access methods which collectively give the illusion that the entire tensor
exists with all of it''s 256 components.
So far, so good. I pretty much agree with his reasoning for distinguishing
between what should properly be represented as a class with private (or
protected) data, as opposed to simply a struct with all public members and
direct user access. I like a lot of the careful discernment found in C++ as
opposed to Java, for example. There are not concepts of constness and
mutable caching in typical Java literature. That shows me C++ has
expressive powers that go well beyond other general purpose languages.
There is however, one point that Stroustrup doesn''t address regarding
''accessor'' methods. He tells us we should avoid writhing classes with
direct accessor methods to manipulate the data. The reasoning seems
obvious to me. If the user has a reason to micro-manage the data, it
probably doesn''t have a clearly defined invariant that could and should be
preserved under the operations applied to it collectively.
The Java community operates with a different philosophy regarding data and
classes. Basically, nothing is public other than static constants, and
accessor methods. The simplest notion of a been in Java is just a class
with data members read and written through the mediation of ''set'' and ''get''
methods. The payoff to this very protective approach to managing data is
that it facilitates such design features as event-listener patterns, and
concurrent programming. The access methods provide a natural means of
locking access to data, and also monitoring access for purposes of event
notification.
One of the more important developments in TC++PL(SE) is the creation of
abstract user interface components as a means of demonstrating the various
options for using inheritance and class hierarchies. Stroustrup argues -
correctly IMO - that a programmer should strive to solve problems
independently of the proprietary libraries he may be developing with.
This is what I have been calling an AUI (abstract user interface) for a few
years. I decided I would try the exercise as part of a project I''m working
on with the goal of visually representing the various access patterens use
to simulate multidimensional arrays using valarray, slices, and gslices.
The program creates a tree of grid cell objects which become the elements
of the graphical representation of the multidimensional matrix.
I created an interface class with all pure virtual functions, and one data
member. The data member is an object that holds default values to be
shared among the different grid elements. This may seem somewhat
convoluted, but it enables me to do some interesting things, such as change
the value of the default values object, notify all the grid cell objects
which own a DefaultBox that their defaults have been changed, and they need
to consider updating.
That demonstrates what I was getting at regarding the use of an
event/listener (observer) pattern to adapt to changes in a particular
object. There''s something else that my design also seems to dictate.
The class used to default initialize grid cells is a good example of what
I''m finding appropriate for my design, and which seems to contradict
Stroustrup''s recommendation to avoid ''set'' and ''get'' functions. That''s
actually a pretty significant part of what my grid cell objects consist of.
That is, data members with read and mutate functions for the data.
#ifndef STHBOXDEFAULTS_H
#define STHBOXDEFAULTS_H
#include <string>
namespace sth
{
using std::string;
/**
@author Steven T. Hatton
*/
class BoxDefaults
{
public:
BoxDefaults( bool is_leaf_ = false,
bool is_vertical_ = false,
string text_ = "[...]",
RgbColor bg_color_ = RgbColor::YELLOW,
RgbColor text_color_ = RgbColor::BLACK,
RgbColor edge_color_ = RgbColor::RED,
double h_ = 35,
double w_ = 50,
double border_w_ = 5,
double x_ = 0,
double y_ = 0,
int bg_z_ = 1,
int text_z_ = 2
)
: is_leaf( is_leaf_ ),
is_vertical( is_vertical_ ),
text( text_ ),
bg_color( bg_color_ ),
text_color( text_color_ ),
edge_color( edge_color_ ),
h( h_ ),
w( w_ ),
border_w( border_w )
{}
virtual ~BoxDefaults(){}
/**
* Are child boxes layed out vertically?
*/
virtual bool Is_vertical() const
{
return this->is_vertical;
}
virtual void Is_vertical(const bool& is_vertical_)
{
this->is_vertical = is_vertical_;
}
/**
* Is this a leaf node?
*/
virtual bool Is_leaf() const
{
return this->is_leaf;
}
virtual void Is_leaf(const bool& is_leaf_)
{
this->is_leaf = is_leaf_;
}
virtual RgbColor Bg_color() const
{
return this->bg_color;
}
virtual void Bg_color(const RgbColor& bg_color_)
{
this->bg_color = bg_color_;
}
/* etc., etc. */
};
}
This seems rather natural to me, but it makes me a bit uneasy, because
Stroustrup has suggested it may not be a good design approach. I will not
that he also insists that his advice and opinions are not intended as
inviolable dictates, nor are they expected to be applicable equally in all
circumstances.
What is your opinion of the use of the ''Java Beans'' design approach? I
realize there is more to a Bean than simply a class with data, events, and
associated listeners. Nonetheless, that seems to be the definitive essence
of what they areally are. There are some aspects of the JavaBean
specification that strike me as arcane and seem to offer far more potential
trouble than potential worth. I do believe the general approach is
something worth understanding, and considering for C++ design. Here''s the
JavaBean spec:
http://java.sun.com/products/javabeans/docs/spec.html
What do you think of these ideas as potentially applicable to C++ code?
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
推荐答案
2004年8月28日星期六04:39:31 -0400，Steven T. Hatton
< su ****** @ setidava.kushan.aa>写道：
[snip]
On Sat, 28 Aug 2004 04:39:31 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote:
[snip]
到目前为止，这么好。我非常赞同他的理由来区分什么应该恰当地表示为具有私人（或
受保护）数据的类，而不是仅仅是一个包含所有公共成员的结构和
直接用户访问权限例如，我喜欢在C ++中发现的许多谨慎的识别与
相反。在典型的Java文献中，没有constness和
可变缓存的概念。这表明我C ++具有远远超出其他通用语言的表达能力。
< OT-advocacy-mode>
每种语言都应该有其优点，这与其他语言的区别在于
给它存在的理由。我只会说我喜欢C ++，因为它可以让开发人员像她喜欢的那样多或者只需要很少的OOP。使用Java，你几乎无法使用OOP
，无论这是否适合手头的任务。
< / OT-advocacy-mode>
我会剪掉其余部分因为我只想评论你的命名
风格：
[ snip] class BoxDefaults
公开：
BoxDefaults（bool is_leaf_ = false，
bool is_vertical_ = false，
string text_ =" [...]" ;，
RgbColor bg_color_ = RgbColor :: YELLOW，
RgbColor text_color_ = RgbColor :: BLACK，
RgbColor edge_color_ = RgbColor :: RED，
double h_ = 35， double w_ = 50，
double border_w_ = 5，
double x_ = 0，
double y_ = 0，
int bg_z_ = 1，
int text_z_ = 2
：
：is_leaf（is_leaf_），
is_vertical（is_vertical_），
text（text_），
bg_color （bg_color_），
text_color（text_color_），
edge_color（edge_color_），
h（h_），
w（w_），
border_w（border_w）
So far, so good. I pretty much agree with his reasoning for distinguishing
between what should properly be represented as a class with private (or
protected) data, as opposed to simply a struct with all public members and
direct user access. I like a lot of the careful discernment found in C++ as
opposed to Java, for example. There are not concepts of constness and
mutable caching in typical Java literature. That shows me C++ has
expressive powers that go well beyond other general purpose languages.
<OT-advocacy-mode>
Every language should have its strong points which distinguish it from
other languages, giving it its reason for existence. I''ll only say
that I like C++ because it allows the developer to be as much or as
little OOP as she likes. With Java, you are pretty much stuck with OOP
whether or not that is the appropriate tool for the task at hand.
</OT-advocacy-mode>
I''ll snip the rest because I merely want to comment on your naming
style:
[snip] class BoxDefaults
{
public:
BoxDefaults( bool is_leaf_ = false,
bool is_vertical_ = false,
string text_ = "[...]",
RgbColor bg_color_ = RgbColor::YELLOW,
RgbColor text_color_ = RgbColor::BLACK,
RgbColor edge_color_ = RgbColor::RED,
double h_ = 35,
double w_ = 50,
double border_w_ = 5,
double x_ = 0,
double y_ = 0,
int bg_z_ = 1,
int text_z_ = 2
)
: is_leaf( is_leaf_ ),
is_vertical( is_vertical_ ),
text( text_ ),
bg_color( bg_color_ ),
text_color( text_color_ ),
edge_color( edge_color_ ),
h( h_ ),
w( w_ ),
border_w( border_w )
^^^^^^^^
哎呀...这里递归初始化！
这就是为什么我不喜欢尾随下划线。
另外，你怎么看待这个：
：is_leaf（is_leaf_）
，is_vertical（is_vertical_）
，text（text_）
，bg_color（bg_color_）
，text_color（text_color_）
，edge_color（edge_color_ ）
，h（h_）
，w（w_ ）
等而不是最后有逗号？我发现它更容易
以避免像这样多余的逗号错误因为我没有必要
读到行尾才能找到它。
-
Bob Hairgrove
否**********@Home.com
" Bob Hairgrove" <在***** @ bigfoot.com>写了...
"Bob Hairgrove" <in*****@bigfoot.com> wrote...
[..]
另外，你怎么看待这个：
：is_leaf（is_leaf_）
，is_vertical（is_vertical_）
，text（text_）
，bg_color（bg_color_）
，text_color（text_color_）
，edge_color（edge_color_）
，h（h_）
，w（w_ ）
等而不是最后有逗号？我发现更容易避免这样多余的逗号错误，因为我没有必要阅读到行尾来找到它。
[..]
Also, what do you think of this:
: is_leaf ( is_leaf_ )
, is_vertical( is_vertical_ )
, text ( text_ )
, bg_color ( bg_color_ )
, text_color ( text_color_ )
, edge_color ( edge_color_ )
, h ( h_ )
, w ( w_ )
etc. as opposed to having the commas at the end? I find it much easier
to avoid superfluous comma errors like this because I don''t have to
read to the end of the line to find it.
这也是我的选择（虽然没有多余的空间）。
使得添加的东西更清晰，特别是到最后，否则
我通常忘记在最后一个初始化之后添加逗号。
V
That''s my choice as well (without the excessive spaces, though).
Makes adding things clearer, especially to the end, when otherwise
I usually forget to add the comma after the last initialiser.
V
Bob Hairgrove写道：
Bob Hairgrove wrote:
2004年8月28日星期六04:39:31 -0400，Steven T. Hatton
< su ****** @ setidava.kushan.aa>写道：
[snip]
On Sat, 28 Aug 2004 04:39:31 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote:
[snip]
到目前为止，这么好。我非常同意他的理由来区分什么应该恰当地表示为具有私有（或受保护）数据的类，而不是仅仅是一个包含所有公共成员和直接结构的结构用户访问权限我喜欢在C ++中发现的很多细心的识别，例如与Java相对的。在典型的Java文献中，没有constness和
可变缓存的概念。这表明我C ++具有远远超出其他通用语言的表达能力。
< OT-advocacy-mode>
每种语言都应该有其优点，这与
其他语言，给它存在的理由。我只会说我喜欢C ++，因为它允许开发人员按照自己喜欢的方式获得尽可能多的OOP。使用Java，你几乎无法使用OOP
这是否适合手头的任务。
< / OT-advocacy-mode>
So far, so good. I pretty much agree with his reasoning for
distinguishing between what should properly be represented as a class with
private (or protected) data, as opposed to simply a struct with all public
members and direct user access. I like a lot of the careful discernment
found in C++ as
opposed to Java, for example. There are not concepts of constness and
mutable caching in typical Java literature. That shows me C++ has
expressive powers that go well beyond other general purpose languages.
<OT-advocacy-mode>
Every language should have its strong points which distinguish it from
other languages, giving it its reason for existence. I''ll only say
that I like C++ because it allows the developer to be as much or as
little OOP as she likes. With Java, you are pretty much stuck with OOP
whether or not that is the appropriate tool for the task at hand.
</OT-advocacy-mode>
在网上的某个地方有一个词法分析器用Java编写。它包含
一个类，所有代码都写成成员函数。除了使用必要的
类来启动事物之外，该程序几乎与C无法区分。我相信很多人都不知道这是Java设计师做出的设计选择的真正意义，
要求所有代码都在一个类中。它并没有真正为应用程序员带来好处
。这样做是因为它有利于JVM加载和执行程序。
在某种程度上，它是一种语言的工件已经实现。
如果你认为顶级类是执行环境的一部分，你会明白，Java和C ++之间的差别要小得多。 >
这方面看起来比其他方式还要好。
正如你所说的那样，这有点偏离主题。我在这里讨论
因为它提供了与C ++的对比，可能有助于巩固理解，并导致用C ++编程的新方法。我不相信Trolltech在开发他们的工具包时努力模仿Java，但是在$ Qt中，在Qt中完成的方式有一些重要的相似之处。
与Java不同，Qt并不限制您使用名称空间本地
声明，但它确实鼓励设计方法将
所有内容放入某些类，并将您的程序视为
交互对象的集合。
注意：以下是伪历史：
想象一下这个。最初的程序是一长串的
指令读入并一个接一个地执行。其中一些
指令能告诉计算机转到并执行先前遇到的指令
并继续从那里继续
，就像这个指令出现在分支点之后。
然后有人决定goto是一个四个字母的单词，并主张放弃使用它的b $ b。结果是隐藏了花哨构造背后的goto指令
，例如函数调用和switch语句。尽管如此，一个程序
仍然是一系列指令要执行，就像计算机读取页面一样，并且理解它可以检查一个
有时交叉引用。这就是C风格的编程。
在古代的某个时刻，发现了一个事件循环的概念。
结果是Emacs。 Emacs后来与C交配，产生了几个b
后代。即XEmacs，ECMAScript（JavaScript），（GNU）Emacs，Mozilla
等。促成这个看似不自然的Lisp联盟和
C的人是一个名叫James Gosling的人。这就是James Gosling，他发明了Java。请注意，当这些想法合并时，会发生一件有趣的事情。一些后代是程序，有些是编程
语言。有些人不能按自己的方式下定决心。
同时这些后代正在产生和/或成熟
更加巧妙地安排了C和Simula之间的联盟。
结果是高度培养和要求严格的C ++。 C ++保留了继承自C的原始
顺序执行模型.C ++是一个
* _programming_language_ *不是一个程序（该死的！）而且那是'基本的
C ++和Java之间的差异。
Somewhere out on the net there is a lexer "written in Java" that consists of
one class with all of the code written as member functions. The program is
virtually indistinguishable from C other than the use of the necessary
class to get the thing bootstrapped. I believe a lot of people are missing
the real significance of the design choice made by the Java designers that
requires all code to be in a class. It wasn''t really done for the benefit
of the application programmer. It was done because it facilitates the
loading and execution of the program by the JVM.
To some extent, it is an artifact of the way the language is implemented.
If you think of the top level class as part of the execution environment,
you will understand there is far less difference between Java and C++ in
this regard than there otherwise may seem.
As you''ve suggested this is somewhat off topic. I''m discussing it here
because it provides a contrast to C++ that might serve to solidify
understanding, and lead to new approaches to programming in C++. I don''t
believe Trolltech strove to emulate Java in developing their toolkit, but
there are some significant similarities in the way things are done in Qt.
Unlike Java, Qt does not restrict you from using namespace local
declarations, but it does encourage the design approach of putting
everything in some class, and treating your program as a collection of
interacting objects.
Note: what follows is pseudo-history:
Think of it like this. Originally programs were a long sequence of
instructions read in and executed one after the other. Some of these
instructions were able to tell the computer to goto and execute a
previously encountered instruction and to continue from there sequentially
as if the instruction had appeared after the branch point.
Then some guy decided goto was a four-letter-word, and advocated banishing
its use. The result was to hide goto instructions behind fancy constructs
such as function calls, and switch statements. Nonetheless, a program
remained a sequence of instructions to be executed as if the computer were
reading down a page, with the understanding that it may examine a
cross-reference at times. That is what C-style programming is.
At some point in the ancient past the notion of an eventloop was discovered.
The result was Emacs. Emacs later mated with C, resulting in several
offspring. Namely XEmacs, ECMAScript (JavaScript), (GNU)Emacs, Mozilla
etc. The person who facilitated this seemingly unnatural union of Lisp and
C was a man named James Gosling. This is the same James Gosling who
invented Java. Note that an interesting thing happened when these ideas
were merged. Some of the offspring are programs, and some are programming
languages. And some can''t make up their mind which way they go.
At the same time as these offspring were being engendered and/or maturing a
more carfully arranged union between C and Simula was consummated. The
result was the highly cultured and demanding C++. C++ retains the original
sequential execution model inherited from C. C++ is a
*_programming_language_* not a program (damnit!) And that''s the fundamental
difference between C++ and Java.
border_w（border_w）
border_w( border_w )
^^^^^^^哎呀...这里递归初始化！
这就是为什么我不喜欢尾随下划线。
^^^^^^^^
Oops ... recursive initialization here!
This is why I do not like trailing underscores.
我不喜欢整个成员初始化工具在C ++中。至于尾随
下划线，我不会经常受到这样的刺痛。只要我保持
一致性，就很容易识别出这样的错误。请注意您的代码
critiquing直接从
开发的程序的编辑缓冲区中复制。我甚至没有完成成员初始化块。任何
系统（如使用尾随下划线）都会出错。
更糟糕的是没有系统。使用领先的
下划线实际上是为实现保留的，尽管程序
可以定义和使用这些标识符而不会产生错误，
如果与实现的使用没有冲突。
另外，你怎么看待这个：
：is_leaf（is_leaf_）
，is_vertical（ is_vertical_）
，text（text_）
，bg_color（bg_color_）
，text_color（text_color_）
，edge_color（edge_color_）
，h（h_）
，w（w_）
等而不是最后有逗号？
我曾经强烈主张将逗号放在这些
续行的开头，但这与我发现的文化背道而驰
我自己。我喜欢这种风格，并且在测试了
KDevelop和Emacs中的自动格式化后，我发现这两个代码都非常相似
很好地对待你的方式如上所示。
我也同意主要括号的位置。我是b / b
尝试替代方案，因为
标识符和左括号之间的长空格也让我感到烦恼。你的
方法更容易看到。
至于尾随下划线，你有什么选择？
我觉得很多更容易
以避免这样多余的逗号错误，因为我没有必要阅读到行尾找到它。
I dislike the entire member initialization facility in C++. As for trailing
underscores, I don''t get stung like that very often. As long as I retain
consistency, it is easy to identify such errors. Note the code you are
critiquing was copied directly out of the edit buffer of a program under
development. I hadn''t even completed the member initialization block. Any
system such as the use of trailing underscores is subject to error. The
only thing worse is to not have a system at all. The use of leading
underscores is actually reserved for the implementation, though a program
can define and use such identifiers without errors being generated,
provided there are not conflicts with the implementations use of the same.
Also, what do you think of this:
: is_leaf ( is_leaf_ )
, is_vertical( is_vertical_ )
, text ( text_ )
, bg_color ( bg_color_ )
, text_color ( text_color_ )
, edge_color ( edge_color_ )
, h ( h_ )
, w ( w_ )
etc. as opposed to having the commas at the end?
I used to be a strong advocate of putting commas at the beginning of such
continued lines, but that was contrary to the culture in which I found
myself. I do like the style, and, after testing the auto-formatting in
KDevelop, and Emacs, I have discovered that both allign the code quite
nicely in the way you have shown above.
I also agree regarding the placement of the leading parentheses. I was
experimenting with the alternative because the long whitespace between the
identifier and the opening parenthesis also bothers me a bit. Your
approach is easier on the eye.
As for trailing underscores, what is your alternative?
I find it much easier
to avoid superfluous comma errors like this because I don''t have to
read to the end of the line to find it.
同意。怎么样的情况如：
bigLongLeftHandSide
= bigLongIdentifier
- > bigLongMemberName
- > yourGonnaWrapSucker
- > bigLongFunctionName（）;
？
- " [M] y不喜欢预处理器是众所周知的。 Cpp在C / $
编程中是必不可少的，并且在传统的C ++实现中仍然很重要，但
它是一个hack，大多数依赖它的技术也是如此。 ......我认为
是时候认真对待无宏C ++编程。 - B. S.
Agreed. What about situations such as:
bigLongLeftHandSide
= bigLongIdentifier
->bigLongMemberName
->yourGonnaWrapSucker
->bigLongFunctionName();
?
-- "[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
这篇关于要bean还是不要bean的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
