英文字典中文字典Word104.com



中文字典辭典   英文字典 a   b   c   d   e   f   g   h   i   j   k   l   m   n   o   p   q   r   s   t   u   v   w   x   y   z   







請輸入英文單字,中文詞皆可:

vaxocentrism    
/vak"soh-sen"trizm/ [analogy with "ethnocentrism"] A notional
disease said to afflict C programmers who persist in coding
according to certain assumptions that are valid (especially
under Unix) on {VAXen} but false elsewhere. Among these are:

1. The assumption that dereferencing a null pointer is safe
because it is all bits 0, and location 0 is readable and 0.
Problem: this may instead cause an illegal-address trap on
non-VAXen, and even on VAXen under OSes other than BSD Unix.
Usually this is an implicit assumption of sloppy code
(forgetting to check the pointer before using it), rather than
deliberate exploitation of a misfeature.

2. The assumption that characters are signed.

3. The assumption that a pointer to any one type can freely be
cast into a pointer to any other type. A stronger form of
this is the assumption that all pointers are the same size and
format, which means you don't have to worry about getting the
casts or types correct in calls. Problem: this fails on
word-oriented machines or others with multiple pointer
formats.

4. The assumption that the parameters of a routine are stored
in memory, on a stack, contiguously, and in strictly ascending
or descending order. Problem: this fails on many RISC
architectures.

5. The assumption that pointer and integer types are the same
size, and that pointers can be stuffed into integer variables
(and vice-versa) and drawn back out without being truncated or
mangled. Problem: this fails on segmented architectures or
word-oriented machines with funny pointer formats.

6. The assumption that a data type of any size may begin at
any byte address in memory (for example, that you can freely
construct and dereference a pointer to a word- or
greater-sized object at an odd char address). Problem: this
fails on many (especially RISC) architectures better optimised
for {HLL} execution speed, and can cause an illegal address
fault or bus error.

7. The (related) assumption that there is no padding at the
end of types and that in an array you can thus step right from
the last byte of a previous component to the first byte of the
next one. This is not only machine- but compiler-dependent.

8. The assumption that memory address space is globally flat
and that the array reference "foo[-1]" is necessarily valid.
Problem: this fails at 0, or other places on segment-addressed
machines like Intel chips (yes, segmentation is universally
considered a {brain-damaged} way to design machines (see
{moby}), but that is a separate issue).

9. The assumption that objects can be arbitrarily large with
no special considerations. Problem: this fails on segmented
architectures and under non-virtual-addressing environments.

10. The assumption that the stack can be as large as memory.
Problem: this fails on segmented architectures or almost
anything else without virtual addressing and a paged stack.

11. The assumption that bits and addressable units within an
object are ordered in the same way and that this order is a
constant of nature. Problem: this fails on {big-endian}
machines.

12. The assumption that it is meaningful to compare pointers
to different objects not located within the same array, or to
objects of different types. Problem: the former fails on
segmented architectures, the latter on word-oriented machines
or others with multiple pointer formats.

13. The assumption that an "int" is 32 bits, or (nearly
equivalently) the assumption that "sizeof(int) ==
sizeof(long)". Problem: this fails on {PDP-11s}, {Intel
80286}-based systems and even on {Intel 80386} and {Motorola
68000} systems under some compilers.

14. The assumption that "argv[]" is writable. Problem: this
fails in many embedded-systems C environments and even under a
few flavours of Unix.

Note that a programmer can validly be accused of vaxocentrism
even if he or she has never seen a VAX. Some of these
assumptions (especially 2--5) were valid on the {PDP-11}, the
original {C} machine, and became endemic years before the VAX.
The terms "vaxocentricity" and "all-the-world"s-a-VAX
syndrome' have been used synonymously.

[{Jargon File}]

vaxocentrism: /vak`soh·sen´trizm/, n. [analogy withethnocentrism’] A notional disease said
to afflict C programmers who persist in coding according to certain
assumptions that are valid (esp. under Unix) on
VAXen but false elsewhere. Among these are:

  1. The assumption that dereferencing a null pointer is safe because it is all
    bits 0, and location 0 is readable and 0. Problem: this may instead cause an
    illegal-address trap on non-VAXen, and even on VAXen under OSes other than BSD
    Unix. Usually this is an implicit assumption of sloppy code (forgetting to
    check the pointer before using it), rather than deliberate exploitation of a
    misfeature.

  2. The assumption that characters are signed.

  3. The assumption that a pointer to any one type can freely be cast into a
    pointer to any other type. A stronger form of this is the assumption that all
    pointers are the same size and format, which means you don't have to worry
    about getting the casts or types correct in calls. Problem: this fails on
    word-oriented machines or others with multiple pointer formats.

  4. The assumption that the parameters of a routine are stored in memory, on a
    stack, contiguously, and in strictly ascending or descending order. Problem:
    this fails on many RISC architectures.

  5. The assumption that pointer and integer types are the same size, and that
    pointers can be stuffed into integer variables (and vice-versa) and drawn back
    out without being truncated or mangled. Problem: this fails on segmented
    architectures or word-oriented machines with funny pointer formats.

  6. The assumption that a data type of any size may begin at any byte address in
    memory (for example, that you can freely construct and dereference a pointer
    to a word- or greater-sized object at an odd char address). Problem: this
    fails on many (esp. RISC) architectures better optimized for
    HLL execution speed, and can cause an illegal address
    fault or bus error.

  7. The (related) assumption that there is no padding at the end of types and that
    in an array you can thus step right from the last byte of a previous component
    to the first byte of the next one. This is not only machine- but
    compiler-dependent.

  8. The assumption that memory address space is globally flat and that the array
    reference foo[-1] is necessarily valid.
    Problem: this fails at 0, or other places on segment-addressed machines like
    Intel chips (yes, segmentation is universally considered a
    brain-damaged way to design machines (see
    moby), but that is a separate issue).

  9. The assumption that objects can be arbitrarily large with no special
    considerations. Problem: this fails on segmented architectures and under
    non-virtual-addressing environments.

  10. The assumption that the stack can be as large as memory. Problem: this fails
    on segmented architectures or almost anything else without virtual addressing
    and a paged stack.

  11. The assumption that bits and addressable units within an object are ordered in
    the same way and that this order is a constant of nature. Problem: this fails
    on big-endian machines.

  12. The assumption that it is meaningful to compare pointers to different objects
    not located within the same array, or to objects of different types. Problem:
    the former fails on segmented architectures, the latter on word-oriented
    machines or others with multiple pointer formats.

  13. The assumption that an int is 32 bits, or (nearly equivalently)
    the assumption that sizeof(int) ==
    sizeof(long)
    . Problem: this fails on PDP-11s, 286-based systems and
    even on 386 and 68000 systems under some compilers (and on 64-bit systems like
    the Alpha, of course).

  14. The assumption that argv[] is
    writable. Problem: this fails in many embedded-systems C environments and even
    under a few flavors of Unix.
Note that a programmer can validly be accused of vaxocentrism even if
he or she has never seen a VAX. Some of these
assumptions (esp. 2--5) were valid on the PDP-11,
the original C machine, and became endemic years before the VAX. The terms
vaxocentricity and all-the-world's-a-VAX syndrome have been used
synonymously.

請選擇你想看的字典辭典:
單詞字典翻譯
Vaxocentrism查看 Vaxocentrism 在Google字典中的解釋Google英翻中〔查看〕
Vaxocentrism查看 Vaxocentrism 在Yahoo字典中的解釋Yahoo英翻中〔查看〕





安裝中文字典英文字典查詢工具!


中文字典英文字典工具:
選擇顏色:
輸入中英文單字

































































英文字典中文字典相關資料:
  • 仿真软件:Cadence中的Calculator使用 (1)——基本操作
    仿真软件:Cadence中的Calculator使用 (1)——基本操作Cadence中Calculator的基本操作Cadence中的Calculator是一个功能强大的工具,它能够帮助用户进行复杂的电路参数计算和仿真数据分析。以下是Calculator的基本操作
  • KaKs_calculator_3. 0计算选择压力ka ks - 百度知道
    KaKs_calculator_3 0计算选择压力ka ks安装KaKs_Calculator3KaKs_Calculator3的下载地址为:ngdc cncb ac cn biocode 解压后,需要添加环境变量
  • cadence calculator中的inl函数使用_百度知道
    cadence calculator中的inl函数使用在Cadence Calculator中,INL(积分非线性)函数的使用需通过参数配置、计算逻辑设置及波形分析完成,主要用于ADC线性度验证。1 采样设置在Cadence Virtuoso的Calculator界面中,
  • 研究帮手| 摩尔浓度及分子量计算工具 molarity-calculator
    l 摩尔浓度计算器 Molarity Calculator l 稀释计算器 Dilution Calculator l 氨基酸转换器 Amino Acids Converter GLPBIO的优势在于,可以直接在手机端使用, 关注公众号 “GLPBIO化合物”或微信小程序 “GLPBIO实验计算器”,即可实现。 包括以下4个计算界面: l 浓度计算 l 溶液稀释
  • Cadence基础教学——以MOS仿真为例(包括calculator的使用)
    关注 展开全部 Cadence基础教学——以MOS仿真为例(包括calculator的使用) 一、MOS仿真基础 Cadence是一款广泛应用于半导体和集成电路设计的软件,其中MOS仿真是模拟电路设计中不可或缺的一部分。 以下将以NMOS和PMOS器件的I-V特性仿真为例,介绍Cadence中的MOS仿真
  • win10打不开计算器了 出现“需要新应用打开此calculator”
    win10打不开计算器了 出现“需要新应用打开此calculator”可按照以下步骤进行查询,操作,具体见下。一、查看别的应用是否也闪退:如果是的话那么可能是服务未开启导致的:1 在Win10下按下WIN+X然后选择“运行”,并
  • 透射电镜数据处理系列-3:计算任意晶体结构的面间距和夹角
    计算任意晶体结构晶面间距和晶面夹角的方法主要涉及公式计算,特别是对于三斜晶系的 (hkl)晶面,晶面间距可通过以下公式计算: 晶面间距公式为: 其中,abcαβγ表示晶格参数,分别为晶胞的三个边长和对应的夹角。 晶面夹角计算公式如下: 此公式适用于晶面指数hkl和两个晶面各自的面间距d1
  • 在cadence里面仿真时如何快速确定仿真波形的频率_百度知道
    在Cadence仿真中,可通过ADE计算器工具、波形自带功能或场效应管特征频率测量方法快速确定仿真波形频率,具体操作如下: 一、使用ADE环境中的计算器工具 进入计算器界面:完成波形仿真后,在ADE环境中选择菜单栏的 Tools -> Calculator,打开计算器工具。 选择信号类型:根据仿真类型(如瞬态分析
  • Aspen plus的计算器(Calculator)还能这么玩儿?自定义你想考察的参数
    Aspen Plus的计算器(Calculator)可通过自定义参数结合Custom Table工具实现非现成参数的实时计算与监控,无需手动重复计算或依赖灵敏度分析。 以下是具体操作步骤和关键要点: 1 确定目标参数与计算逻辑
  • 天选R74800RTX3050玩calculator,刚进游戏一会风扇就转得厉害声音比较大怎么回事?
    天选R74800RTX3050玩calculator,刚进游戏一会风扇就转得厉害声音比较大怎么回事?“天选R74800RTX3050”玩“Calculator”游戏时风扇转速快、声音大的核心原因,是硬件温度升高触发散热系统加速运转。 具体可能由以下





中文字典-英文字典  2005-2009

|中文姓名英譯,姓名翻譯 |简体中文英文字典