语言标准：最小公分母与效用 [英] Language standard: the least common denominator vs. utility
问题描述
在这个论坛上不断出现的一件事是
标准C缺少很多功能，这些功能在工作站或服务器上是必需的，但在嵌入式控制器中是不可能的。
这导致过多的不要问这里，
在comp.xy中询问，用于查询来自
的函数程序员可用的
文档似乎是C语言的b / b
。我认为很大程度上是因为这个最不常见的b $ b分母 C语言标准我们有POSIX，XPG4等，其中
添加这些有用且在许多情况下必要的部分。而这个标准的多样性可能是一个真正的痛苦。我宁愿
编写符合_ONE_语言标准的代码而不是编写代码
必须符合_MANY_相关语言标准。
仅仅是为了争论，
ISO / ANSI C标准是否非常错误地定义与洗碗机控制器不同的计算机相关功能？b $ b例如，如果语言
需要编译器为目标平台定义这些常量为
0（不存在）或1或更高（存在，数字表示各种
未来修订级别）：
ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKING
ISOC_CAPABILITY_INTERPROCESS
等
代码可以测试这些，如果存在，则使用相关的
支持的功能。例如，如果定义了MULTIUSER，那么
某种形式的getusername将支持。
请注意，这或多或少是编译器现在所做的，除了
常量引用POSIX，XPG4等，它并不包括
能力，但包括语言扩展，后者很少与前者明显相关。这导致疯狂凌乱
编译器提供的包含文件，通过逻辑来确定posix，xpg4，ansi等的哪个组合通常很难跟踪
>
必须在编译时设置才能获得所需的功能。
对于那些从事嵌入式控制器工作的纯粹主义者来说，这些潜在的可用性是多少？额外的功能应该没有任何问题。
他们完全免费不使用它们。交叉编译器将使用b $ b否定这些常量，以便任何意外尝试使用目标平台不支持的函数的代码将被标记为
编译时间。
问候，
David Mathog
One thing that keeps coming up in this forum is that
standard C lacks many functions which are required in
a workstation or server but not possible in an embedded controller.
This results in a plethora of "don''t ask here,
ask in comp.x.y instead", for queries on functions that from the
documentation available to the programmer appear to be part
of the C language. I think largely because of this "least common
denominator" C language standard we have POSIX, XPG4, etc, which
add these useful and in many instances necessary pieces. And this
multiplicity of standards can be a real pain. I would really rather
write code that complies with _ONE_ language standard than write code
that has to comply with _MANY_ interrelated language standards.
Just for the sake of argument, would it be so terribly wrong for the
ISO/ANSI C standard to define capabilities relevant for computers
other than dishwasher controllers? For instance, if the language
required the compiler define for the target platform these constants as
0 (not present) or 1 or higher (present, with number indicating various
future revision levels):
ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKING
ISOC_CAPABILITY_INTERPROCESS
etc.
The code could test for these, and if present, utilize the relevant
supported functions. For instance, if MULTIUSER was defined then
some form of "getusername" would be supported.
Note that this is more or less what compilers do now, except that the
constants refer to POSIX, XPG4, etc, and it is not so much including by
capability, but including by language extension, with the latter rarely
clearly associated with the former. This results in insanely messy
compiler provided include files in which it is often painful to trace
through the logic to determine which combination of posix,xpg4,ansi etc
must be set at compile time to obtain the desired functions.
For those purists who work on embedded controllers the potential
availability of these extra functions should pose no problem whatsoever.
They are perfectly free NOT to use them. The cross compiler would
negate these constants so that any code that accidentally tried to
use a function not supported on the target platform would be flagged at
compile time.
Regards,
David Mathog
推荐答案
David Mathog写道：
David Mathog wrote:
在这个论坛上不断出现的一件事是
标准C缺少很多功能
a工作站或服务器中需要但在嵌入式控制器中不可能。这个
导致过多的不要问这里，
在comp.xy中询问，用于查询来自
的函数程序员可用的
文档似乎是C语言的b / b
。我认为很大程度上是因为这个最不常见的b $ b分母 C语言标准我们有POSIX，XPG4等，其中
添加这些有用且在许多情况下必要的部分。而这个标准的多样性可能是一个真正的痛苦。我宁愿
编写符合_ONE_语言标准的代码而不是编写代码
必须符合_MANY_相关语言标准。
仅仅是为了争论，
ISO / ANSI C标准是否非常错误地定义与洗碗机控制器不同的计算机相关功能？b $ b例如，如果语言
需要编译器为目标平台定义这些常量为
0（不存在）或1或更高（存在，数字表示各种
未来修订级别）：
One thing that keeps coming up in this forum is that
standard C lacks many functions which are required in
a workstation or server but not possible in an embedded controller. This
results in a plethora of "don''t ask here,
ask in comp.x.y instead", for queries on functions that from the
documentation available to the programmer appear to be part
of the C language. I think largely because of this "least common
denominator" C language standard we have POSIX, XPG4, etc, which
add these useful and in many instances necessary pieces. And this
multiplicity of standards can be a real pain. I would really rather
write code that complies with _ONE_ language standard than write code
that has to comply with _MANY_ interrelated language standards.
Just for the sake of argument, would it be so terribly wrong for the
ISO/ANSI C standard to define capabilities relevant for computers
other than dishwasher controllers? For instance, if the language
required the compiler define for the target platform these constants as
0 (not present) or 1 or higher (present, with number indicating various
future revision levels):
[...]
这个确切的讨论似乎在参考文献中弹出嵌入式世界中常见的大量
语言。例如，当
Forth被标准化时，有很多关于各种平台可以提供的各种各样的功能的讨论，以及其中有多少将是
包含在标准中。
他们最终定义了一个核心。标准有许多特定的可选
功能。符合Forth的实现只需要满足
核心要求并说明它支持哪些可选功能。
所以，这种事情已被采用用其他语言。我不是很熟悉ISO C标准，以评论那里是否有类似的情况。
[...]
This exact discussion seems to pop up in reference to a great number of
languages that are common in the embedded world. For example, when
Forth was standardized there was a lot of discussion about the sorts of
capabilities various platforms could provide, and how much of that would
be included in the standard.
They ended up defining a "core" standard with many specific optional
capabilities. A conforming Forth implementation just has to satisfy the
core requirements and state which of the optional capabilities it supports.
So, this sort of thing has been adopted in other languages. I''m not
familiar enough with the ISO C standard to comment on whether there are
similar situations there.
在文章< eh ********** @ naig.caltech.edu>
David Mathog< ma **** @ caltech.eduwrote：
In article <eh**********@naig.caltech.edu>
David Mathog <ma****@caltech.eduwrote:
>仅仅为了争论，
ISO / ANSI C标准定义与计算机相关的功能是否会非常错误
其他洗碗机控制器？例如，如果语言需要编译器为目标平台定义这些常量为
0（不存在）或1或更高（存在，数字表示各种未来的修订级别）：
ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKINGISOC_CAPABILITY_INTERPROCESS
代码可以测试这些，如果存在，请使用相关的
支持的功能。例如，如果定义了MULTIUSER那么某种形式的getusername会得到支持。
>Just for the sake of argument, would it be so terribly wrong for the
ISO/ANSI C standard to define capabilities relevant for computers
other than dishwasher controllers? For instance, if the language
required the compiler define for the target platform these constants as
0 (not present) or 1 or higher (present, with number indicating various
future revision levels):
ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKING
ISOC_CAPABILITY_INTERPROCESS
etc.
The code could test for these, and if present, utilize the relevant
supported functions. For instance, if MULTIUSER was defined then
some form of "getusername" would be supported.
这种事情已经用其他语言标准完成了。
结果通常似乎是：
a）核心语言标准不是很好，因为
标准化小组在
外围设备上花费了相当多的精力。零件并没有多余的时间留给
核心部分。
b）外围设备。零件*真的*很臭。 :-)
从功能上来说，这与我们现在拥有的b $ b $之间没有什么区别：
This sort of thing has been done in other language standards.
The result generally seems to be:
a) the "core" language standard is not as good, because the
standardizing-group spent a fair bit of effort on the
"peripheral" parts and had little time left over for the
"core" part.
b) the "peripheral" parts *really* stink. :-)
Functionally, there is no real difference between this and what we
have now:
>请注意，这或多或少是编译器现在所做的，除了
常量指的是POSIX，XPG4等，并不是包含
功能，而是包括通过语言扩展，后者很少与前者明确相关。这导致了疯狂凌乱的编译器提供的包含文件，在这些文件中通常很难通过逻辑来确定必须在编译时设置posix，xpg4，ansi等的哪个组合。获得所需的功能。
>Note that this is more or less what compilers do now, except that the
constants refer to POSIX, XPG4, etc, and it is not so much including by
capability, but including by language extension, with the latter rarely
clearly associated with the former. This results in insanely messy
compiler provided include files in which it is often painful to trace
through the logic to determine which combination of posix,xpg4,ansi etc
must be set at compile time to obtain the desired functions.
....除了在现在之外例如，当ISO C与POSIX发生冲突时，
很清楚当你选择ISO
C时你应该得到哪一个？或POSIX。这可能并不明显*怎么做*，但至少
标准形成组是独立的，因此（逻辑上讲，至少
）更负责任。< br $> b $ b -
In-Real-Life：风河系统公司Chris Torek
美国犹他州盐湖城（40°39.22'' N，111°50.29''W）+1 801 277 2603
电子邮件：忘了它 http://web.torek.net/torek/index.html
阅读电子邮件就像在垃圾中搜索食物一样，感谢垃圾邮件发送者。
.... except that, in the "now" case, when ISO C conflicts with POSIX,
it is pretty clear which one you *should* get when you select "ISO
C" or "POSIX". It may not be obvious *how* to do it, but at least
the Standard-forming groups are independent and hence (at least
logically speaking) more accountable.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22''N, 111°50.29''W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
文章< eh ********** @ naig.caltech.edu>，
David Mathog< ; ma **** @ caltech.eduwrote：
In article <eh**********@naig.caltech.edu>,
David Mathog <ma****@caltech.eduwrote:
>只是为了争论，对于
ISO /它是否会如此严重错误ANSI C标准用于定义与洗碗机控制器以外的计算机相关的功能？例如，如果语言需要编译器为目标平台定义这些常量为
0（不存在）或1或更高（存在，数字表示各种未来的修订级别）：
>Just for the sake of argument, would it be so terribly wrong for the
ISO/ANSI C standard to define capabilities relevant for computers
other than dishwasher controllers? For instance, if the language
required the compiler define for the target platform these constants as
0 (not present) or 1 or higher (present, with number indicating various
future revision levels):
> ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKINGISOC_CAPABILITY_INTERPROCESS
等
>ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKING
ISOC_CAPABILITY_INTERPROCESS
etc.
>代码可以测试这些，如果存在，则使用相关的
支持的功能。例如，如果定义了MULTIUSER那么某种形式的getusername会得到支持。
>The code could test for these, and if present, utilize the relevant
supported functions. For instance, if MULTIUSER was defined then
some form of "getusername" would be supported.
看一下这个特定列表，我注意到一些语义上的困难。
我正在使用的Unix操作系统目前有IPv6功能，但是我们还没有配置任何IPv6接口（或基础设施）。
从理论上讲，当我们运行二进制文件时，我们可能会有 - 或者我们
可能希望二进制文件可以在其他系统上使用，而这些操作系统可能碰巧配置了IPv6接口。
<因此，任何功能都需要在语义上区分，
系统知道这个系列的功能和结构
并且可以编译和链接和他们一起与这是在二进制文件正在运行的
系统上启用。
类似地，虽然我的操作系统支持IPv6，但我可能知道在
内，二进制文件的有效生命周期，我们不会在任何具有IPv6实际配置的系统上运行它：因此，应该是
可以使用相应的一系列覆盖来说即使系统支持它也不要使用
这个功能。
其次，标准化过程总是喜欢看一下
示例实现（以证明它可以在没有太多麻烦的情况下完成），并且希望看到示例实现具有
实际上已成功使用。因此，我建议从标准化水平开始，然后建立一个autoconfig库
，用于探测特征的标准化方法，以及
标准化的功能命名约定。
想象一下，例如，类似CPAN（Comprehensive Perl
存档网络）的设施，带有界面允许人们轻松搜索特定功能测试的
并加载测试结构，然后
" include"在任何特定的
项目的一个'的automake配置文件中。与CPAN一样，应该有版本。功能测试
可用和新版本的通知机制;并且
应该是版本号的主要和次要组件（主要
数字更改，表示在定义的
名称列表中向后不兼容） 。由于成功探测另一个功能，一个功能的成功探测器可能依赖于
，探测器脚本应该具有相同的perl'的'require'和 - 如果你还没有这样做的话，运行这样一个和b $ b特征测试。此外，功能测试可能会最终相互关联，因此您需要对您的
已安装进行依赖性检查。功能测试......如果你想要功能测试，那么
负载依赖于你还没有加载的东西（或者需要
a更新的版本of），你想选择自动安装
缺失或更新的版本。
这是一个可以完成的项目de事实上" - 一堆
的人可以聚在一起，让它成为现实。
如果你真的*野心勃勃，你可以试试统一 ;
常用例程库 - 已经具有所有系统依赖性的代码
内置，以完成超出的所需任务$ / b $ b标准C提供的设施，以及如上所述的基础设施
，用于检测和加载新版本。
（任何类似的东西 - 可能最好是以不透明的方式完成
类型。）但你可能会因为决定包含什么以及不透明的界面看起来像什么而陷入困境......
-
如果你撒谎到编译器，它将报复。 - Henry Spencer
Looking at that -particular- list, I notice some semantic difficulties.
The Unix OS I''m using at the moment has IPv6 capabilities, but
we haven''t configured any IPv6 interfaces (or infrastructure).
Theoretically, by the time we run the binary, we might have -- or we
might want the binary to be usable on other systems with exactly the
same OS which might happen to have IPv6 interfaces configured.
Thus, any capabilities need to semantically distinguish between,
"the system knows about this family of functions and structures
and can compile and link with them" versus "this is enabled on the
system the binary is running on right now".
Similarily, although my OS supports IPv6, I might know that within
the effective lifetime of the binary, that we will not run it on
any system with IPv6 actually configured: therefore, there should
be available a corresponding series of overrides to say "don''t use
this feature even though the system supports it".
Secondly, the standardization processes always like to see an
example implementation (to prove that it can be done without a lot
of trouble), and like to see that the example implementation has
actually been successfully used. I would thus propose that instead
of starting at the standardization level, that an autoconfig library
be built up, of standardized ways to probe for a feature, and
standardized feature naming conventions.
Imagine, for example, a facility sort of like CPAN (Comprehensive Perl
Archive Network), with an interface that allowed one to easily search
for a particular feature test and load the test structure in, and then
"include" that in one''s automake configuration file for any particular
project. Like CPAN, there should be "versions" of the feature test
available and a mechanism to be notified of new versions; and there
should be major and minor components to the version number (major
number changes indicating backwards incompatabilities in the list of
names defined). And as successful probes for one feature might depend
upon successful probes for another feature, the probe scripts should
have the equivilent of perl''s "require" -- i.e., run such and such a
feature test if you haven''t already done so. Also, feature tests could
end up interrelated, so you would want dependancy checking against your
"installed" feature tests... and if the feature test you''d like to
load down relies upon something you haven''t already loaded in (or need
a newer version of), you''d like the option of automatically installing
the missing or newer versions.
This is a project that could be done "de facto" -- a bunch of
people could just get together and Make It Happen.
If you were *really* ambitious, you could try a "Unified" library of
common routines -- code that already had all the system dependancies
built in, in order to accomplish the required tasks that were beyond
the facilities provided by Standard C, together with the infrastructure
such as described above to detect and load in new versions.
(Anything like that -might- perhaps best be done in terms of opaque
types.) But you could probably bog yourself down just in deciding
what to include and what the opaque interfaces should look like...
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
这篇关于语言标准：最小公分母与效用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
