ANSI C合规性 [英] ANSI C compliance
问题描述
只是为了在这里提出一个切入点，以防任何新来的人不知道所有这些火焰战争是什么。
简写标题：如果我写了100％ANSI C代码，我的老板会解雇我
我们正在讨论这个新闻组是否应该关注100％ANSI C或
只是与现实世界中C语言相关的主题。有一个由国际委员会定义的C
标准。编写
编译器的人会参考这个，以确保他们的编译器遵循
标准 - 他们实际编译C。但是，他们还添加扩展
到C语言，让你的生活更轻松，当然还有编译器等等的错误。
所以对于各种原因，你写的哪个运行并在一个
平台上按预期工作可能不适用于另一个平台。 C标准在那里
减轻这个 - 决定哪个编译器在
行为上有所不同。
有多少百分比的非平凡程序完全是ANSI C（即它们在你拥有ANSI C编译器，modulo
编译器错误的所有平台上按预期工作？b $ b）？我怀疑接近0％的地方，就像大约0％的
非平凡的程序完全没有bug。即使把这个带到
账户，我也会怀疑不到5％的非平凡的C程序是打算用的，或者实际上是标准的C.它只是没有必要
工程实践，虽然肯定有例外。例如，
我曾经采访过的一项工作是编写
许可技术的标准ANSI C实现，这些技术旨在（手工）移植到
被许可人提供的DSP。也就是说，我的想法是为其他人写一些东西来阅读和编译，而不是真正用于实际产品的东西。
现在，在在我看来。如果你没有经验，在这个新闻组中写下真正标准的C值，如常客那样，b $ b是很费时的。并且需要
的时间来积累必要的知识。因此，在商业世界中，它不被视为良好的做法，因为时间=金钱。
有一个你可能会打电话的研究领域软件开发，这是研究真实团队如何构建真正的软件产品。有一个概念
称为投机性一般性 （从史蒂夫麦康奈尔的一本书中我可以看到，不要这么想，请记住哪一个，另见马丁福勒）。这基本上就是当你用
编写代码来推测你将来需要编写的内容时。
而不是编写完全符合你需要的代码，你写的东西是b $ b的东西，可能更多。这是
过度工程的简写 - 当一个特定的系统需要
时，构建一个通用系统。
写入100％ANSI C当你不处于特殊情况时（比如我上面列出的那个）我被认为是投机性的一般性。可移植性是代码的b $ b特征。考虑使用9位字节进行移植或
2堆栈或无堆栈或6堆栈是浪费时间（至少营业时间，
您的个人时间是免费的当你不喜欢的时候，你可以花钱，但是你没有可疑的需要。因为这段时间可以用于实际需要的实时功能，实际产生金钱的功能。
即使你有可预见的需求，它也被认为是良好的做法
解决__手头的问题_。业务要求非常好b $ b b volatile。高管们善变。
一个例子。我们的游戏开始于PS2。几年前，我们将它移植到了GameCube和XBox上。我们最初是否有完全可移植的代码？
不，我们为PS2写了一个游戏。如果有的话，它会更容易移植吗？
当然，一点点。但是，解决所有问题并不是什么大问题，因为他们用* real *编译器编译了b $ b。所以我们这样做了，直接用
方式。
我们现在有移植它的标准C代码吗？不，我们需要吗？实际上，产品销售超过150万份并且产生了数百万美元的利润。
现在我们是调查将其移植到PSP（Playstation Portable）。如果我们有标准的C代码会更容易吗？当然，有点。但是，如果我们
永远不必移植到PSP怎么办？那么我们写标准C的努力会浪费掉b
。如果PSP编译器有一个错误的错误，使得它与ANSI C不兼容，那该怎么办？ （并非不可能，因为一般来说这些机器只有一个编译器
）。
在软件开发中，*会产生开发成本*功能*当你需要它时* b $ b需要它*。不是更快。
所以，最重要的是，如果我正在制作一些旧的讨厌的代码，
符合ANSI C标准，而不是实现我的日程安排上的一项功能
（ANSI C合规将被嘲笑时间表），我的老板将是
PISSED。你不这样做。
已经正常工作的代码存在一个非常真实的风险，这当然比那些没有代码的代码更糟糕。
ANSI C.
那就是说，你应该学习语言的基本规则（合理的b
点，肯定有收益递减点）。太多的程序员盲目地破解，只是试图关闭编译器警告。
（信不信由你，我实际上是团队中最坚持的人<严格按照标准来衡量，例如，当人们使用enum
作为整数时，我就是讨厌它的人，即使这是标准的等等。我的同事会有一个
好好嘲笑这个，并想知道这个新闻组是否来自另一个星球。）
所以，第二个底线是，这是C编程现实世界，绝大多数人都有兴趣做的事情。
。因为
反对在一个新闻组中打击他们的ANSI C知识作为一个
本身。这就是为什么CLC是一个讨论ANSI C，
的可怕场所，因为已经有了非常好的地方（CLC.moderated）。这是新来的人往往会来的地方（如上所述，alt.comp.lang.learn-c-c ++是其标题的笑话），和CLC.moderated会拒绝他们的许多帖子
作为主题。因为他们不知道标准C是什么，他们不知道
什么是主题。
美好的一天。如果您对此有合理的回应，我会对您的意见感兴趣。
（但是，唉，让火焰从常客开始......
Roose
Roose写道：
我们正在讨论这个新闻组是否应该专注于100％ANSI C或仅仅是与现实世界中C语言相关的主题。有一个由国际委员会定义的C
标准。编写
编译器的人会参考这个，以确保他们的编译器符合
标准 - 他们实际编译C.
的确如此。编写C程序的人参考它来确保他们的
程序是C程序。
但是，他们还添加了C语言的扩展名来制作你的生活更轻松，当然还有编译器中的错误等等。
存在其他新闻组来讨论与特定相关的扩展
实现和平台。请在其他新闻组中进行特定于平台的讨论
。谢谢。
< snip>
-
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书等：< a rel =nofollowhref =http://users.powernet.co.uk/etontarget =_ blank> http://users.powernet.co.uk/eton
"卢斯" <无**** @ nospam.nospam>写在
新闻：3Z ****************** @ newssvr14.news.prodigy.c om：
只是为了在这里提出切入点，以防新来的人不知道所有这些火焰战争是什么。
简写标题：我的老板会如果我写了100％ANSI C代码，那就解雇我吧
我们正在讨论这个新闻组是应该关注100％ANSI C
还是仅仅关注现实世界中与C语言相关的主题。有一个由国际委员会定义的C标准。
编写编译器的人参考这个是为了确保他们的编译器遵循标准 - 他们实际编译C.
但是，他们还添加了C语言的扩展，以使您的生活更轻松，当然编译器中也存在错误等。
让我稍微改写一下这个段落：
comp.lang.c是一个专门讨论C的新闻组
编程语言。 C编程语言由
国际委员会定义，其定义由ISO发布。人们
编写符合此标准的编译器，否则他们将无法编译C.许多C编译器也有不符合标准的模式
作为扩展，使其行为类似于语言的编译器
类似但不同于C.
所以出于各种原因，你写的是C在一个平台上按预期运行和工作可能无法在另一个平台上运行。 C标准是为了缓解这一点 - 如果它们的行为不同，决定哪个编译器是错误的。
嗯......这一个：
标准的某些部分是定义的，所以有些C程序
在另一个平台上的表现会有所不同。 C标准定义了用C编译器编译的程序的
行为，其中部分是
implimentation定义要求行为由
$ b记录$ b供应商。任何编译器在编译C程序时都会生成一个行为不同于
标准所定义的行为的可执行文件，编译后的源代码不是C编译器。 />
有多少百分比的非平凡程序完全是ANSI C（即它们在你拥有ANSI C
编译器，模数编译器错误的所有平台上按预期工作）？我怀疑接近0％的地方，
就像大约0％的非平凡程序完全没有bug一样。
即使考虑到这一点，我也会怀疑不到5％的
非编写的-trivial C程序旨在或实际上是标准C.它不是必需的工程实践，尽管
肯定有例外。例如，我曾经接受采访的一项工作是编写许可技术的标准ANSI C实现，这些技术旨在（由手工）移植到许可证持有者的DSP上。也就是说，这个想法是为其他人写一些东西来阅读和编译，而不是实际用于真正的产品。
现在，我的观点。写下真正的标准C，由常客评估。如果你没有经验，在这个新闻组中很费时间。并且需要时间来积累必要的知识才能这样做。因此，在商业世界中，它不被认为是好的实践，因为时间=金钱。
如果您的目的是学习C，那么就这样做。这就是通常在这里讨论的
。如果你想学习几乎但不是C-from-a-specific
的供应商，那么也有新闻组。
< snip>这是过度工程的简写 - 当一个特定的系统会做的时候构建一个通用系统。
我没有看到用C语言写作是否过度工程与写一些供应商提供的语言相似。我不再需要用C语言编写
而不是用C语言写一篇文章，我很熟悉
with。
当你不处于特殊情况时（例如我上面列出的那个）写100％ANSI C被认为是推测性的一般性。
可移植性是代码的一个特性。考虑使用9位字节或2个堆栈或没有堆栈或6个堆栈的机器的可移植性是浪费时间（至少业务时间，您的个人时间可以免费使用你喜欢的，当你没有可预见的需求时。
因为这个时间可以用于实际需要的功能，实际产生金钱的功能。即使你对它有可疑的需求，只需要解决问题就可以了解_问题。业务要求极不稳定。
高管们变幻无常。
实际上，考虑可移植性问题是浪费时间，而b $ b涉及使代码在这样一系列系统上运行。这就是为什么我们将
留给C编译器程序员为我们做这件事。他们担心那些
的东西，而且我可以在C安全的代码中知道我的程序
会按照我的意图去做。
< snip使用C语言但是特定于供应商的商业示例和
他们之间移植的努力，以及所说的财务成功
项目>
在软件开发中，*当您需要*时，*会产生功能的开发成本*。不是更快。
的确如此。这就是为什么我在合理的时候用C语言写作，而不是用它来特定的imp
。如果我需要做一些需要
供应商特定代码的事情，我会在最近可能的机会做到这一点而不是最早的b $ b。我只需要花费必要时检查和学习
供应商特定部件的费用。
所以，最重要的是，如果我正在制作一些旧的讨厌代码符合ANSI C标准，而不是在我的日程安排上实现一项功能（ANSI C合规性会被计划嘲笑），我的
老板会被PISSED。你不这样做。在已经正常工作的代码中创建错误存在非常大的风险，这当然比那些不是ANSI C的代码更糟糕。
当然，如果你没有用C编程开始，那么你的日程安排需要花费时间才能将它变成C语言。就个人而言，如果合理的话，我会坚持使用C语言写作
，并且只在需要时才进入供应商特定的非C / $
扩展。
< snip>
（但是，唉，让常客的火焰开始......）
Roose
*手上有些阻燃内衣... *
Ian Woods
我会回答这个问题作为一个严肃的答案，即使你正在尝试用理查德推广的游戏反驳我的论点 - 假装
唯一存在的是这个新闻组讨论的内容。关于ANSI C之外的事情，我的文章是
，所以为了正确理由，你一定不能玩这个游戏。
伊恩伍兹 <是ne ****** @ wuggyNOCAPS.org>在留言中写道
新闻：Xn ***************************** @ 217.32.252.50 ..." Roose" <无**** @ nospam.nospam>在
新闻中写道：3Z ****************** @ newssvr14.news.prodigy.c om：现在，转到我的点。写下真正的标准C，由常客评估。如果你没有经验，在这个新闻组中很费时间。并且需要时间来积累必要的知识才能这样做。因此，在商业世界中，它不被认为是好的实践，因为时间=金钱。
如果你的目的是学习C，那么就这样做。这就是通常在这里讨论的内容。如果你想学习几乎但不是C-from-a-specific-
供应商，那么也有新闻组。
我'我不是在说你。或我。我说的是一个真正的开发团队，这是一个真正的产品。在这样的团队中，_as fact_，你将会遇到旧代码，代码是由你自己以外的人编写的。旧代码
可能不是用ANSI C编写的。
< snip>这是过度工程的简写 - 建立一个特定系统的常规系统。
我不知道用C语言写作是否过度工程与写作
相比C喜欢某些供应商提供的语言。我不再用C语言写作了比用C语言写的几乎用C语言来表达我熟悉的
。
再次，我不是在谈论你。我说的是你可能正在使用的普通程序员。如果你是一名项目经理，如果这样的程序员对ANSI C不是很熟悉 - 你会怎么做？
你会为他安排额外的时间吗？他的代码是ANSI兼容的，还是
你会安排足够的时间让它进入一个很好的可读的状态，适合进一步修改吗？
当你不处于特殊情况时（如我上面列出的那个）写100％ANSI C被认为是推测性的一般性。
便携性是代码的一个特征。考虑使用9位字节或2个堆栈或没有堆栈或6个堆栈的机器的可移植性是浪费时间（至少业务时间，您的个人时间可以免费使用你喜欢的，当你没有可预见的需求时。
因为这个时间可以用于实际需要的功能，实际产生金钱的功能。即使你对它有可疑的需求，只需要解决问题就可以了解_问题。业务需求非常不稳定。
高管们变幻无常。
实际上，浪费时间考虑使代码工作所涉及的可移植性问题。这样一系列的系统。这就是我们将它留给C编译器程序员为我们做的原因。他们担心这些东西，我可以在C中安全地编写代码，知道我的程序将完成我打算做的事情。
点了，但我仍然认为可移植性是一个特性。使代码符合ANSI标准需要花费额外的费用。
在软件开发中，*会产生功能的开发成本*
*当你需要它时*。不是很快。
的确如此。这就是为什么我在合理的时候用C语言写作，而不是用于具体的imp。如果我需要做一些需要特定供应商特定代码的事情，我会在最新的机会而不是最早的时候这样做。我只需要在必要时检查和学习供应商特定部件的成本。
同样的逻辑适用，而不是谈论你。
Roose
Just to make a tangential point here, in case anyone new to C doesn''t
understand what all these flame wars are about.
Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"
We are discussing whether this newsgroup should focus on 100% ANSI C or
simply topics related to the C language in the real world. There is a C
standard which is defined by an international committee. People who write
compilers refer to this in order to make sure their compilers follow the
standard -- that they actually compile C. However, they also add extensions
to the C language to make your life easier, and of course there are bugs in
the compilers and such.
So for various reasons, C you write which runs and works as expected on one
platform might not work on another platform. The C standard is there to
alleviate this -- to decide which compiler is wrong if they differ in
behavior.
What percent of non-trivial programs are completely ANSI C (i.e. they work
as intended on all platforms for which you have an ANSI C compiler, modulo
compiler bugs)? I would suspect somewhere near 0%, just like about 0% of
non-trivial programs are completely bug free. Even taking this into
account, I would suspect less than 5% of non-trivial C programs written are
intended to be, or actually are, standard C. It simply isn''t necessary
engineering practice, although there are certainly exceptions. For example,
one job I once interviewed for was writing standard ANSI C implementions of
licensed technology, that were meant to be ported (by hand) to assembly on
DSPs by the licensees. That is, the idea was to write something for other
people to read and compile, not something to actually go in a real product.
Now, on to my point. Writing truly standard C as valued by the "regulars"
in this newsgroup is time-consuming if you''re not experienced. And it takes
time to accumulate the knowledge necessary to do so. Thus, in the business
world, it is not considered good practice, since time = money.
There is a field of study you might call "software development", which is
the study of how real teams build real software products. There is a notion
called "speculative generality" (from one of Steve McConnell''s books I
think, don''t
remember which one, see also Martin Fowler). This is basically when you
write code that speculates on what you may need to write need in the future.
Instead of writing code that does exactly what you need to do, you write
something that does more than that, potentially. This is shorthand for
overengineering -- architecting a general system when a specific one will
do.
Writing 100% ANSI C when you are not in a special circumstance (like the one
I listed above) is considered speculative generality. Portability is a
feature of code. Thinking about portability to machine with 9 bit bytes or
2 stacks or no stack or 6 stacks is a waste of time (at least business time,
your personal time is free to be spent however you like), when you have no
forseeable need for it. Because this time could be spent working on
features that actually are required, ones that actually generate money.
Even if you DO have a forseeable need for it, it is considered good practice
to solve _only the problem at hand_. Business requirements are extremely
volatile. Executives are fickle.
An example. Our game started out on PS2. A couple years ago we ported it
to the GameCube and XBox. Did we have completely portable code at first?
No, we wrote a game for PS2. Would it have been easier to port if we had?
Sure, a little. But it wasn''t a big deal to fix all the problems as they
came up, as compiled with *real* compilers. And so we did so, in a
straightforward manner.
Do we have standard C code now that we ported it? No. Do we need to? Not
really, the products sold more than 1.5 million copies and generated
millions of dollars in profits.
Now we are investigating porting it to PSP (Playstation portable). Would
it be easier if we have standard C code? Sure, a little. But what if we
never had to port to PSP? Then our effort writing standard C would have
been wasted. What if the PSP compiler has a bad bug that makes it
incompatible with ANSI C? (Not unlikely, since there is only one compiler
for these machines at first, generally).
In software development, *incur the development cost* of a feature *when you
need it*. Not any sooner.
So, the bottom line is, if I was working on making some old nasty code that
works ANSI C compliant, instead of implementing a feature on my schedule
(ANSI C compliance would be laughed off the schedule), my boss would be
PISSED. You don''t do that. There is a very real risk of creating bugs in
already working code, which of course is much worse than that code not being
ANSI C.
That said, you should learn the basic rules of the language (to a reasonable
point, there is definitely a point of diminishing returns). Far too many
programmers hack blindly, just trying to shut the compiler warnings up.
(Believe it or not, I am actually the one on the team that adheres most
strictly to standards, e.g. I am the one who hates it when people use enum
as integers, even though that is standard, etc.. My co-workers would have a
good laugh at this, and wonder if this newsgroup is from another planet.)
So, the second bottom line is, that this is C programming in the real world,
which the overwhelming majority of people are interested in doing. As
opposed to whacking off in a newsgroup about their ANSI C knowledge as an
end in itself. That is why CLC is a terrible place to discuss ONLY ANSI C,
as there is already perfectly good place (CLC.moderated). This is where
people new to C tend to come (as mentioned, alt.comp.lang.learn-c-c++ is a
joke by its very title), and CLC.moderated would reject many of their posts
as off topic. Since they don''t KNOW what standard C is yet, they don''t know
what''s on-topic.
Good day. If you have a reasoned response to this, I''d be interested in
your opinions.
(But alas, let the flames from the "regulars" begin...)
Roose
Roose wrote:
We are discussing whether this newsgroup should focus on 100% ANSI C or
simply topics related to the C language in the real world. There is a C
standard which is defined by an international committee. People who write
compilers refer to this in order to make sure their compilers follow the
standard -- that they actually compile C.
Indeed. And people who write C programs refer to it to ensure that their
programs are C programs.
However, they also add
extensions to the C language to make your life easier, and of course there
are bugs in the compilers and such.
Other newsgroups exist to discuss the extensions relating to particular
implementations and platforms. Please take up platform-specific discussions
in those other newsgroups. Thank you.
<snip>
--
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
"Roose" <no****@nospam.nospam> wrote in
news:3Z******************@newssvr14.news.prodigy.c om:
Just to make a tangential point here, in case anyone new to C doesn''t
understand what all these flame wars are about.
Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"
We are discussing whether this newsgroup should focus on 100% ANSI C
or simply topics related to the C language in the real world. There
is a C standard which is defined by an international committee.
People who write compilers refer to this in order to make sure their
compilers follow the standard -- that they actually compile C.
However, they also add extensions to the C language to make your life
easier, and of course there are bugs in the compilers and such.
Let me rewrite this paragraph a little:
comp.lang.c is a newsgroup dedicated to discussions about the C
programming language. The C programming language is defined by an
international committee and it''s definition is published by ISO. People
write compilers which conform to this standard because otherwise they
wouldn''t be compiling C. Many C compilers also have a non-conforming mode
as an extension which makes it behave like a compiler for a language
which is similar to but different from C.
So for various reasons, C you write which runs and works as expected
on one platform might not work on another platform. The C standard is
there to alleviate this -- to decide which compiler is wrong if they
differ in behavior.
Hmmm... and this one:
Some parts of the standard are implimentation defined, so some C programs
will behave differently on another platform. The C standard defines the
behaviour of programs compiled with a C compiler, and where parts are
implimentation defined requires that the behaviour is documented by the
vendor. Any compiler which, when compiling a C program, produces an
executable with behaviour different to that defined by the standard for
the compiled source is not a C compiler.
What percent of non-trivial programs are completely ANSI C (i.e. they
work as intended on all platforms for which you have an ANSI C
compiler, modulo compiler bugs)? I would suspect somewhere near 0%,
just like about 0% of non-trivial programs are completely bug free.
Even taking this into account, I would suspect less than 5% of
non-trivial C programs written are intended to be, or actually are,
standard C. It simply isn''t necessary engineering practice, although
there are certainly exceptions. For example, one job I once
interviewed for was writing standard ANSI C implementions of licensed
technology, that were meant to be ported (by hand) to assembly on DSPs
by the licensees. That is, the idea was to write something for other
people to read and compile, not something to actually go in a real
product.
Now, on to my point. Writing truly standard C as valued by the
"regulars" in this newsgroup is time-consuming if you''re not
experienced. And it takes time to accumulate the knowledge necessary
to do so. Thus, in the business world, it is not considered good
practice, since time = money.
If your intention is to learn C, then do so. That is what is typically
discussed here. If you want to learn almost-but-not-C-from-a-specific-
vendor then there are newsgroups for that too.
<snip>This
is shorthand for overengineering -- architecting a general system when
a specific one will do.
I don''t see how writing in C is overengineering compared to writing in ''a
C like language provided by some vendor''. It takes me no longer to write
in C than it does to write in almost-C for an implimentation I''m familiar
with.
Writing 100% ANSI C when you are not in a special circumstance (like
the one I listed above) is considered speculative generality.
Portability is a feature of code. Thinking about portability to
machine with 9 bit bytes or 2 stacks or no stack or 6 stacks is a
waste of time (at least business time, your personal time is free to
be spent however you like), when you have no forseeable need for it.
Because this time could be spent working on features that actually are
required, ones that actually generate money. Even if you DO have a
forseeable need for it, it is considered good practice to solve _only
the problem at hand_. Business requirements are extremely volatile.
Executives are fickle.
Indeed, it''s a waste of time thinking about the portability issues
involved in making code work on such an array of systems. That''s why we
leave it to C compiler programmers to do it for us. They worry about that
stuff, and I can just code in C secure in the knowledge that my program
will do what I intended it to do.
<snip business example of using languages like-C but vendor specific and
the effort of porting between them, and the financial success of said
project>
In software development, *incur the development cost* of a feature
*when you need it*. Not any sooner.
Indeed. This is why I write in C whenever reasonable, rather than for a
specific implimentation of it. If I need to do something which requires
vendor specific code, I do it at the latest possible opportunity rather
than earliest. I only incur the cost of having to examine and learn the
vendor specific parts when necessary.
So, the bottom line is, if I was working on making some old nasty code
that works ANSI C compliant, instead of implementing a feature on my
schedule (ANSI C compliance would be laughed off the schedule), my
boss would be PISSED. You don''t do that. There is a very real risk
of creating bugs in already working code, which of course is much
worse than that code not being ANSI C.
Certainly, if you''re not programming in C to begin with then it takes
time in your schedule to make it into C later. Personally, I''ll stick
with writing in C when reasonable, and only go into vendor specific non-C
extentions when they''re needed.
<snip>
(But alas, let the flames from the "regulars" begin...)
Roose
*hands Roose some flame retardant underwear...*
Ian Woods
I''m going to respond to this as a serious answer, even though you are trying
to refute my arguments with a game popularized by Richard -- pretend that
the only thing that exists is what this newsgroup discusses. My article was
about things outside ANSI C, so to reason about it correctly, you must not
play that game.
"Ian Woods" <ne******@wuggyNOCAPS.org> wrote in message
news:Xn*****************************@217.32.252.50 ..."Roose" <no****@nospam.nospam> wrote in
news:3Z******************@newssvr14.news.prodigy.c om:Now, on to my point. Writing truly standard C as valued by the
"regulars" in this newsgroup is time-consuming if you''re not
experienced. And it takes time to accumulate the knowledge necessary
to do so. Thus, in the business world, it is not considered good
practice, since time = money.
If your intention is to learn C, then do so. That is what is typically
discussed here. If you want to learn almost-but-not-C-from-a-specific-
vendor then there are newsgroups for that too.
I''m not talking about "you" or "I". I''m talking about a real development
team, that makes a real product. On such a team, _as a fact_, you will
encounter old code, code written by someone other than yourself. Old code
that is likely not written in ANSI C.
<snip>This
is shorthand for overengineering -- architecting a general system when
a specific one will do.
I don''t see how writing in C is overengineering compared to writing in ''a
C like language provided by some vendor''. It takes me no longer to write
in C than it does to write in almost-C for an implimentation I''m familiar
with.
Again, I''m not talking about "you". I''m talking about the average
programmer who you might be working with. If you were a project manager, if
such a programmer was not very familiar with ANSI C -- what would you do?
Would you schedule extra time for him to make his code ANSI compliant, or
would you schedule just enough time for him to get it into a nice readable
state, suitable for further modification?
Writing 100% ANSI C when you are not in a special circumstance (like
the one I listed above) is considered speculative generality.
Portability is a feature of code. Thinking about portability to
machine with 9 bit bytes or 2 stacks or no stack or 6 stacks is a
waste of time (at least business time, your personal time is free to
be spent however you like), when you have no forseeable need for it.
Because this time could be spent working on features that actually are
required, ones that actually generate money. Even if you DO have a
forseeable need for it, it is considered good practice to solve _only
the problem at hand_. Business requirements are extremely volatile.
Executives are fickle.
Indeed, it''s a waste of time thinking about the portability issues
involved in making code work on such an array of systems. That''s why we
leave it to C compiler programmers to do it for us. They worry about that
stuff, and I can just code in C secure in the knowledge that my program
will do what I intended it to do.
Point taken, but I still contend that portability is a feature. It costs
extra to make code ANSI compliant.
In software development, *incur the development cost* of a feature
*when you need it*. Not any sooner.
Indeed. This is why I write in C whenever reasonable, rather than for a
specific implimentation of it. If I need to do something which requires
vendor specific code, I do it at the latest possible opportunity rather
than earliest. I only incur the cost of having to examine and learn the
vendor specific parts when necessary.
Same logic applies, not talking about "you".
Roose
这篇关于ANSI C合规性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
