rust - 将 `#![no_std]` 添加到库时，该库的用户是否有任何缺点或复杂性？

Question

我写了一个 Rust 库。我听说过 no_std 功能，并注意到我的库没有使用 std 中 core 未提供的任何内容和 alloc .所以理论上我可以只添加 #![no_std] 属性并更改一些导入。

但我想知道这对我图书馆的用户有何影响。当然，我希望通过使用 #![no_std]，no_std 环境中的用户也可以使用我的 crate。那当然很好。但是:我的库的用户是否因为我的库是 no_std 而有任何缺点？例如，他们是否被迫也使用 #![no_std]?那会很糟糕。我想知道，因为大多数 crate 隐藏了 Cargo 功能背后的 no_std 兼容性。我实际上在网上找不到关于这个问题的任何信息。

如果使用#![no_std] 没有任何缺点，那么每个可以在没有std 的情况下工作的 crate 都应该添加该属性，对吧？

Answer 1

For example, are they forced to also use #![no_std]?

完全没有。依赖包(即，将使用您的包的包/项目)将知道找到您的依赖项所需的 core 包，并且可以像 no_std 一样自由使用它 曾经参与过。主要区别在于对这种依赖的期望以及有多少其他 crate 可以使用它。换句话说，如果该依赖项是为 no_std 准备的，那么与您的依赖项兼容的 crate 集应该始终是一个超集。

readme of KodrAus/rust-nostd ，一个在库中使用和测试 no_std 的示例，还建议尽可能使用 no_std 以获得最大兼容性:

The current design of Rust's standard library is split into a few layers, each building on the assumed platform capabilities of the one below. There's:

• std: the full standard library assumes the presence of threads, a filesystem, and networking. [...]
• alloc: the collections layer builds on the core by assuming runtime support for dynamic memory allocation.
• core: the core layer makes no (well, not very many) assumptions about the > underlying platform. Just about any target that can run Rust code is supported by core.

So when you're designing your library you can make it maximally portable by targeting the lowest layer of the standard library that you can.

一些 crate 将 no_std 放在 Cargo 特性后面的原因是因为 crate 可能包含一些需要 std 的选择加入功能，或者至少 分配。通过以 Cargo 功能为条件，没有标准库的环境仍然可以使用 crate，而那些具有 std 或 alloc 的环境可以使用 crate 的扩展 API。下面是显示此功能的“lib.rs”示例。

#![cfg_attr(not(feature = "std"), no_std)]

#[cfg(feature = "std")]
extern crate core;

#[cfg(feature = "alloc")]
extern crate alloc;

pub fn foo_into_slice(slice: &mut [u8]) { unimplemented!() }

/// Vec requires alloc
#[cfg(feature = "alloc")]
use alloc::vec::Vec;

#[cfg(feature = "alloc")]
pub fn foo_into_vec(vec: &mut Vec<u8>) { unimplemented!() }