为什么`std::env::args`返回一个`String`迭代器而不是`&'static str`？

Question

我记得在操作系统课上学到，至少在我们所学的操作系统中，命令行参数被存储在进程的地址空间中。如果是这样的话，那么std::env::Args不就可以是&'static str迭代器吗？或者，如果字符串的编码不一定是UTF-8且与操作系统有关，那么std::env::ArgsOs不就可以是&'static OsStr迭代器吗？

- Michael Hewson

---

fn main() { let name = String::new(); } — “name” 也被“存储在进程的地址空间中”。也许你的意思是其他的？ - Shepmaster

Answer 1

这是你的答案。仅仅因为一个操作系统在内存中按字面意思存储命令行参数，并不意味着所有操作系统都是这样的。更何况，有什么办法可以保证它们以与 `str` 函数所期望的完全相同的格式存储它们吗？

最简单的例子是Windows，在 Windows 中，命令行是从函数调用返回的单个潜在无效的 UTF-16 字符串：没有办法将其转换为 `&'static str`。

因此，该 API 的设计是基于返回一个拥有所有权的字符串，因为它必须在各个平台上保持一致，并且不知道如何将命令行参数转换为可用格式。

- DK.

---

那么标准的 C 主函数 int main(int argc, charg**argv) 在 Windows 上无法工作？ - Michael Hewson

它确实会起作用，但是它是通过C运行时在调用“main”之前解析命令行来实现的。从操作系统的角度来看，它是一个兼容性支撑而不是本地工作方式。 - DK.

我也在想同样的问题，但是我一直在寻找std::env::args_os()返回OsString迭代器而不是std::ffi::OsStr的原因。你有什么想法吗？ - U007D