[我意识到这个问题已有一百万年的历史,但它的核心还有一个(或两个)更深层次的问题,关于 OP、编程的教学法以及关于假设的问题。]
包括模组在内的一些人认为这是不可能的。而且,在某些——包括最明显的——上下文中,确实如此。但有趣的是,这对 OP 来说并不是很明显。
不可能假设contex 在面向行的文本控制台(例如,console+sh 或X-term+csh 或Terminal+bash)上运行从C 编译的可执行文件,这是一个非常合理的假设。但是,“正确”答案(“ %8d
”)对于 OP 来说还不够好,同时也不明显,这一事实表明附近有相当大的蠕虫罐头……
考虑诅咒(及其许多变体)。在其中,您可以导航“屏幕”,“移动”光标,以及“重绘”基于文本的输出部分(窗口)。在 Curses 上下文中,绝对可以这样做;即,动态调整“窗口”的大小以容纳更大的数字。但即使是 Curses 也只是屏幕“绘画”的抽象。没有人建议它,而且可能是正确的,因为C中的 Curses 实现并不意味着它是“严格的 C”。美好的。
但这究竟意味着什么?为了使响应:“不可能”是正确的,这意味着我们正在谈论运行时系统。换句话说,这不是理论上的(如“如何对一个静态分配的int
s 数组进行排序?”),这可以解释为完全忽略运行时任何方面的“封闭系统”。
但是,在这种情况下,我们有 I/O:特别是printf()
. 但这就是有机会说一些更有趣的东西作为回应的地方(尽管,诚然,提问者可能没有挖得这么深)。
假设我们使用一组不同的假设。假设 OP 相当“聪明”并且理解不可能在面向行的流上编辑先前的行(您将如何更正行打印机输出的字符的水平位置??)。还假设 OP 不仅仅是一个做家庭作业的孩子,却没有意识到这是一个“技巧”问题,旨在梳理对“流抽象”含义的探索。此外,让我们假设 OP 想知道:“等等……如果 C 的运行时环境支持 STDOUT 的想法——如果 STDOUT 只是一个抽象——为什么拥有一个 1) 可以的终端抽象不是一样合理垂直滚动但 2) 支持可定位光标?两者都在屏幕上移动文本。
因为如果这是我们试图回答的问题,那么您只需要看:
ANSI 转义码
看到:
几乎所有的视频终端制造商都添加了供应商特定的转义序列来执行操作,例如将光标放在屏幕上的任意位置。一个例子是 VT52 终端,它通过发送 ESC 字符、一个 Y 字符和两个表示等于 x,y 位置加 32 的数值的字符,允许将光标放置在屏幕上的 x,y 位置(因此从 ASCII 空格字符开始并避免控制字符)。Hazeltine 1500 具有类似的功能,使用 ~、DC1 调用,然后用逗号分隔 X 和 Y 位置。虽然这两个终端在这方面具有相同的功能,但必须使用不同的控制序列来调用它们。
第一个支持这些序列的流行视频终端是 1978 年推出的 Digital VT100。该型号在市场上非常成功,引发了各种 VT100 克隆,其中最早和最受欢迎的是价格更实惠的 Zenith Z -19 在 1979 年。其他包括 Qume QVT-108、Televideo TVI-970、Wyse WY-99GT 以及可选的“VT100”或“VT103”或“ANSI”模式,在许多其他品牌上具有不同程度的兼容性。这些的流行逐渐导致越来越多的软件(尤其是公告板系统和其他在线服务)假设转义序列有效,导致几乎所有新的终端和仿真程序都支持它们。
早在 1978 年就有可能。C 本身是在 1972 年“诞生”的,而 K&R 版本是在 1978 年建立的。如果当时有“ANSI”转义序列,那么“in C”就有一个答案,如果我们也愿意规定:“好吧,假设您的终端支持 VT100。” 顺便说一句,不支持 ANSI 转义的控制台?你猜对了:Windows 和 DOS 控制台。但在几乎所有其他平台(Unices、Vaxen、Mac OS、Linux)上,您都可以期待。
TL;DR - 如果不说明有关运行时环境的假设,就无法给出合理的答案。由于大多数运行时(除非您使用 80 年代和 90 年代的台式计算机市场份额来计算“大多数”)都会有(从 VT-52 时代开始!),那么我不'认为说这是不可能的完全有道理 - 只是为了让它成为可能,这是一个完全不同数量级的工作,而不是那么简单%8d
......它似乎有点像 OP 知道的.
我们只需要澄清假设。
以免有人认为 I/O 是异常的,即,我们唯一需要考虑运行时(甚至硬件)的时候,只需深入研究 IEEE 754 浮点异常处理。对于那些感兴趣的人:
英特尔浮点案例研究
根据加州大学伯克利分校的威廉·卡汉教授的说法,1996 年 6 月发生了一个经典案例。一枚名为阿丽亚娜 5 的卫星运载火箭在发射后不久就转动了车轮,并将自身和价值超过 50 亿美元的有效载荷散落在法国的一片沼泽中圭亚那。Kahan 发现这场灾难可归咎于一种无视 IEEE 754 中默认异常处理规范的编程语言。发射后,传感器报告的加速度如此之大,以至于导致用于重新校准火箭惯性的软件转换为整数溢出在发射台上进行指导。