K& R-Style函数声明：好还是坏？ [英] K&R-Style Function Declarations: Good or Bad?
问题描述
我倾向于使用相当描述性的参数名称，因此旧式的
声明对我很有吸引力，因为我可以在80个字符内保留一个声明：
void * newKlElem（frame_size，num_blocks，num_frames，frame_locator）
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *定位器;
{
/ *代码在这里* /
我'我们发现很多人都鄙视这种声明，而且还有一些人说他们会在未来的标准中被弃用。我应该避免这样的事情，或者继续按照我的意愿行事吗？
-
迈克的专利阻止列表;用gcc编译：
i = 0; o（a）{printf（"％u"，i>> 8 * a& 255）; if（a）{printf（ "。"）; o（ - a）;}}
main（）{do {o（3）; puts（""）;} while（++ i） ;}
I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:
void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */
I''ve found many who despise this sort of declaration, and also some who
say it''s going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?
--
Mike''s Patented Blocklist; compile with gcc:
i=0;o(a){printf("%u",i>>8*a&255);if(a){printf(".") ;o(--a);}}
main(){do{o(3);puts("");}while(++i);}
推荐答案
On Sun，07 Dec 2003 23:13:17 -0800，Michael B.
< us ***** @ spamblocked.com>在comp.lang.c中写道：
非常，非常非常糟糕。
On Sun, 07 Dec 2003 23:13:17 -0800, "Michael B."
<us*****@spamblocked.com> wrote in comp.lang.c:
Very, very, VERY bad.
我倾向于使用相当描述性的名称作为参数，所以
声明的旧样式对我很有吸引力，因为我可以在80个字符内保留一个声明：
void * newKlElem（frame_size，num_blocks，num_frames，frame_locator）
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator * locator;
请注意，这是一个函数定义和声明，但
它不是原型。
您是否意识到完整的原型定义不需要在单行上适用
？
这又如何更好：
void * newKlElem（size_t frame_size，unsigned short num_blocks，
unsigned short num_frames，Kl_frame_locator * locator）
.. ..（比你的垂直线少）或：
void * newKlElem（
size_t frame_size，
unsigned short num_blocks，
unsigned short num_frames，
Kl_frame_locator * locator）
....它不会比你的更多垂直线????
{
/ *代码在这里* /
我发现很多人鄙视这种声明，还有一些人说它将在未来的标准中被弃用。我应该避免这样的事情，还是继续按照我的意愿行事？
I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:
void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
Note that this is a function definition as well as a declaration, but
it is not a prototype.
You do realize that full prototype definitions are not required to fit
on a single line?
And how is this any better than:
void *newKlElem (size_t frame_size, unsigned short num_blocks,
unsigned short num_frames, Kl_frame_locator *locator)
....(which takes fewer vertical lines than yours) or:
void *newKlElem (
size_t frame_size,
unsigned short num_blocks,
unsigned short num_frames,
Kl_frame_locator *locator )
....which takes no more vertical lines than yours???
{
/* code goes here */
I''ve found many who despise this sort of declaration, and also some who
say it''s going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?
预标准函数定义不会为
创建原型
这个函数。 C在其整个存在中对C的最重要的改进是添加了真正的函数原型。要因为风格原因放弃这个优势似乎不是一个好的想法。
还有一个问题保持原型与
定义同步。从标准
定义生成或更新原型就像复制文本，将其粘贴到
头文件或需要原型的任何地方一样简单，并添加;
后右括号。
-
Jack Klein
主页： http://JK-Technology.Com
comp.lang.c http：/ /www.eskimo.com/~scs/C-faq/top.html
comp.lang.c ++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang .learn.c-c ++ ftp://snurse-l.org/ pub / acllc -c ++ / faq
The pre-standard function definition does not create a prototype for
the function. The single most important improvement to C in its
entire existence was the addition of real function prototypes. To
give up that advantage for style reasons does not seem like a good
idea.
There is also the issue of keeping prototypes in sync with
definitions. Generating or updating a prototype from a standard
definition is as simple as copying the text, pasting it into the
header file or wherever the prototype is needed, and adding a ; after
the closing right parenthesis.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
？o？太阳，2003年12月7日23:13:17 -0800 ???迈克尔B. ?????°???
?o? Sun, 07 Dec 2003 23:13:17 -0800???Michael B.?????°???
我倾向于使用相当描述性的参数名称，所以
声明的旧样式对我很有吸引力，因为我可以在80个字符内保留一个声明：
void * newKlElem（frame_size，num_blocks，num_frames，frame_locator）
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator * locator;
{
/ *代码在这里* /
我'已经发现许多人鄙视这种声明，还有一些人说它将在未来的标准中被弃用。我应该避免这样的事情，还是继续按照我的意愿行事？
I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:
void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */
I''ve found many who despise this sort of declaration, and also some who
say it''s going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?
我更喜欢这种声明只是因为它的可读性
和清澈。
-
没有什么比一个装满Gap小孩的咖啡馆更加珍贵了。你是不是真的穿着橡皮裤。
- 迈克史密斯
I prefer this kind of declaration just because of its readability
and clearness.
--
There''s nothing so precious as a cafe full of Gap kiddies trying to
work out whether you''re really wearing rubber pants.
-- Mike Smith
Michael B.写道：
Michael B. wrote:
我倾向于使用相当描述性的参数名称，因此旧式的
声明对我很有吸引力，因为我可以在80个字符内保留一个声明：
void * newKlElem（frame_size，num_blocks，num_frames，frame_locator）
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator * locator;
{
/ *代码来到这里* /
我发现很多人都鄙视这种声明，还有一些人说这将是d在未来的标准中豁免。我应该避免这样的事情，还是继续按照我的意愿行事？
I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:
void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */
I''ve found many who despise this sort of declaration, and also some who
say it''s going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?
我不建议这样做。 netKlElem上面的定义不是
原型。如果你不提供你自己的原型，那么随后的
调用它可能没有任何类型检查，并将通过
默认参数促销。
请注意如果上面的源文件
编译时没有原型，并且维护原因可能会导致奇怪的情况
程序员决定将一个放入另一个头文件或源文件中。如果
原型的类型与*默认参数促销后的原始
函数*的类型不匹配，那么行为是
undefined。
这听起来很人为，但实际上在多个文件中需要
函数时会发生，并且有人会去静电它和
将原型添加到某处的标题中。
Mark F. Haigh
mf ***** @ sbcglobal.net
I don''t recommend doing this. netKlElem''s definition above is not a
prototype. If you don''t provide your own prototype, then subsequent
calls to it may not have any type checking, and will go through the
default argument promotions.
Be aware of the strange situation that may result if your source file
above is compiled without a prototype in scope, and a maintenence
programmer decides to put one into another header or source file. If
the prototype''s types do not match with the types of the original
function *after* default argument promotions, then the behavior is
undefined.
This sounds contrived, but can actually happen in practice when a
function is needed in more than one file, and somebody de-statics it and
adds a prototype to a header somewhere.
Mark F. Haigh
mf*****@sbcglobal.net
这篇关于K& R-Style函数声明：好还是坏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
