评估顺序和更好的职能声明
这篇文章包含一个问题和一个提案。
A.我可以知道为什么没有在
C / C ++中指定参数评估的顺序？
我在comp.lang.c ++中询问了以下可能性的问题和
因为语言没有指定评估顺序，所以这样做
是一个错误。
int B :: f（int i，int j = i + 1）{// j默认为i + 1
....
}
（那些人建议使用多态或致电
另一个类的构造函数。）
B.如果指定了这样的订单，我们不仅可以根据以前的参数默认参数
，我们可以声明方法/功能
更好。想一想：
//文件foo.h
//这个例子来自固定的参数评估顺序
//但是它如果我们不允许，则没有必要有固定的订单
引用
//来自参数的先前参数
（int * ）B :: f（
int i {//此处记录并在运行时断言
i> 0&& i< INT_MAX
}，
int j = i + 1 {
j> i || j< 0
}，
int * k {
k！= NULL&& k！= some_global
}
）//结束参数记录断言现在返回值''s
转
（
！= NULL
）;
执行时，B :: f的序言可以接受每个参数并断言。
第一个参数只能对常量和全局变量断言。
如果没有指定评估顺序，其他参数跟随
套件
其他他们的asser tions和默认赋值（如果有的话）可能包括
之前的参数。
然后B :: f'的正文被执行
然后B： ：如果
any，则检查f'的返回值（如果有的话）。
[我觉得害羞建议默认返回值 ;功能。]
这个方案有三个优点：
1.它有助于沟通前提条件，后期条件非常好
清楚（BIG加）
2.它使函数f的定义更清晰
3. Splint和其他lint依赖于特别注释的代码来写
关于代码的假设。这种方法正在用
断言替换注释并使代码更加健壮。
我可以看到这个方案的五个问题 - 其中一些很容易
求解
1.在
..h文件中可能无法始终解析全局和外部。
2.它可以以计算时钟周期的方式进行。样式C因为
的隐藏断言。 [一个好的代码无论如何都必须有这些断言。
下面的
＃3解决了这个问题。]
3.这些断言必须是绕过能力的。发布的代码。 [但是，
在编译器中提供选项会这样做。即使这样，所有与b $ b参数相关的断言现在也可以在.h
文件中一目了然。]
4.它有必要将代码链接到< assert.h>或等价物。
[再一次，一个好的代码必须有这个。]
5.断言中的函数调用可能变得讨厌。 [最糟糕的是，
我们可以禁止那里的函数调用。]
你的评论？
-Bhushit
This post contains one question and one proposal.
A. May I know why order of evaluation of arguments is not specified in
C/C++?
I asked a question in comp.lang.c++ for the following possibility and
because the languages do not specify the order of evaluation, doing so
was an error.
int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
....
}
(Folks there suggested either to use polymorphism or to call
constructor of another class.)
B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:
// file foo.h
// This example gains from fixed order of evaluation of arguments
// but it is not necessary to have fixed order if we disallow
references to
// previous arguments from an argument
(int *) B::f (
int i { //document here and assert at run time
i > 0 && i < INT_MAX
},
int j = i + 1 {
j > i || j < 0
},
int *k {
k != NULL && k!= some_global
}
) // end of argument documented assertion now return value''s
turn
(
!= NULL
);
Upon execution, prologue to B::f may take each argument and assert.
The first argument can be asserted only against constants and globals.
If order of evaluation is not specified, other arguments follow the
suite
else their assertions and default assignment if any, may include
previous argument.
Then B::f''s body gets executed
Then B::f''s return value (if any) is checked against assertions if
any.
[I feel shy of suggesting a "default return value" for a function.]
This scheme has three advantages:
1. It facilitates communicating pre-conditions, post-conditions very
clearly (BIG plus)
2. It makes definition of function f clearer
3. Splint and other lints depend on specially annotated code to write
assumptions about the code. This approach is replacing annotation with
assertion and making code more robust.
I can see five problems with this scheme - some of them are easy to
solve
1. It may not always be possible to resolve globals and externs in a
..h file.
2. It may come in way of "counting the clock cycles" styled C because
of hidden assertions. [ A good code must have those assertions anyway.
#3 below solves this.]
3. These assertions must be "bypass-able" for released code. [However,
provision of an option in compiler would do that. Even then, all
argument related assertions are now viewable at a glance in a .h
file.]
4. It makes necessary to link the code to <assert.h> or equivalent.
[Once again, a good code must have this anyway.]
5. Function calls within assertions may become nasty. [At the worst,
we can disallow function calls there.]
Your comments?
-Bhushit
Bhushit Joshipura写道：
Bhushit Joshipura wrote:
这篇文章包含一个问题和一个提案。
A.我可以知道为什么在C / C ++中没有指定参数评估的顺序吗？
This post contains one question and one proposal.
A. May I know why order of evaluation of arguments is not specified in
C/C++?
我想到的两个最明显的答案是：
1）为什么会这样？
2）
标准化时可能存在冲突的实现，没有人想要在委员会中给予支持。
第一个答案是，恕我直言，引人注目。确定参数评估顺序没有特别的好处，并且不这样做会给予
编译器编写者许可以优化其平台的评估订单。
-
Richard Heathfield： bi **** @ eton.powernet.co.uk
Usenet是一个奇怪的地方。 - Dennis M Ritchie，1999年7月29日。
C FAQ： http://www.eskimo.com/~scs/C-faq/top.html
K& R答案，C书等： http://users.powernet.co.uk/eton
The two most obvious answers that spring to mind are:
1) why should it be?
2) perhaps conflicting implementations existed at the time of
standardisation, and nobody wanted to give ground in committee.
The first answer is, IMHO, compelling. There is no particular benefit to
pinning down the order of evaluation of arguments, and not doing so gives
compiler writers licence to optimise evaluation orders for their platforms.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Bhushit Joshipura写道：
Bhushit Joshipura wrote:
这篇文章包含一个问题和一个提案。
A.我可以知道为什么在C / C ++中没有指定参数的评估顺序？
到目前为止一直很好，除了没有一种叫做C / C ++的语言。
我在comp.lang.c ++中提出了一个问题，提出了以下可能性
因为语言没有指定评估顺序，所以这样做是错误的。
int B :: f（int i，int j = i + 1） {// j默认为i + 1
...
}
然而这是C ++代码，并使其成为clc的所有OT
（有人建议使用多态或调用另一个类的构造函数。）
This post contains one question and one proposal.
A. May I know why order of evaluation of arguments is not specified
in C/C++?
So far so good, except that there is no language called C/C++.
I asked a question in comp.lang.c++ for the following possibility
and because the languages do not specify the order of evaluation,
doing so was an error.
int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
...
}
However this is C++ code, and makes it all OT for c.l.c.
(Folks there suggested either to use polymorphism or to call
constructor of another class.)
语言C没有多态或构造函数或者
班级。 OT on clc
.... snip ...
指定参数评估的顺序会失效
标准编写时的代码很多。这也将限制未来的聪明才智。它有记录，所以相应的程序。
f''ups设置。
-
查克F （cb********@yahoo.com）（cb********@worldnet.att.net）
可用于咨询/临时嵌入式和系统。
< http://cbfalconer.home.att.net>使用worldnet地址！
The language C has none of polymorphism or constructors or
classes. OT on c.l.c.
.... snip ...
Specifying order of parameter evaluation would have invalidated
much code when the standard was written. It would also restrict
future ingenuity. It is documented, so program accordingly.
f''ups set.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
" Bhushit Joshipura" < BH ***** @ hotmail.com>在消息中写道
news：84 ************************** @ posting.google.c om ...
"Bhushit Joshipura" <bh*****@hotmail.com> wrote in message
news:84**************************@posting.google.c om...
这篇文章包含一个问题和一个提案。
A.我可以知道为什么在C / C ++中没有指定参数评估的顺序吗？
我在comp.lang.c ++中提出了一个问题，提出了以下可能性和
因为语言没有指定评估顺序，所以这样做是错误的。
int B :: f（int i，int j = i + 1）{// j默认为i + 1
}
（那些人建议要么使用多态，要么调用另一个类的构造函数。）
B.如果指定了这样的命令，我们不仅可以默认一个参数
基于以前的论点，我们可以更好地声明方法/功能。想一想：
This post contains one question and one proposal.
A. May I know why order of evaluation of arguments is not specified in
C/C++?
I asked a question in comp.lang.c++ for the following possibility and
because the languages do not specify the order of evaluation, doing so
was an error.
int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
...
}
(Folks there suggested either to use polymorphism or to call
constructor of another class.)
B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:
我猜这些参数几乎总是从右到左进行评估
就是你在这里给出的特殊例子在更复杂的类型的一般情况下，以最佳的
效率。
左右评价的原因可能主要是历史 -
对于古代C，你需要能够在没有
声明的情况下处理调用函数（varargs的相同问题）和最简单有效的方法
那就是以相反的顺序将参数推到堆栈上，这样首先就可以找到
了。
我能想到的唯一原因按照arbirary顺序进行的评估是，现代编译器/处理器倾向于在寄存器中传递一些args，这些寄存器也可能用于计算，因此在评估中可能更有效。
任意订单（但请注意，这也有利于逆转订单作为寄存器
可能需要在arg列表中计算参数''later''
I would guess that arguments are almost always evaluated right to left which
makes the particular example that you give here hard to do with optimal
efficiency in the general case of more complicated types.
The reason for right to left evaluation is probably mainly historical now -
For ancient C you needed to be able to deal with calling functions without a
declaration (same problem for varargs) and the simplest efficient way to do
that is to push the arguments in reverse order onto the stack so that the
first is readily findable on top.
The only reason I can think of for evaluation in arbirary order is that
modern compiler/processors tend to pass some args in registers that may also
be used for calculations and hence it may be more efficient to evaluate in
arbitrary order (But note this also favours reverse order as the registers
may be needed to calculate arguments ''later'' in the arg list)