我正在扩展一个Rust项目。来自C++世界,我正在寻找一个类似namespace
的概念。
Rust项目的文件结构如下所示:
src
|
|--lib.rs
|
|--examples/example.rs
|
|--level1
| |---verify.rs // pub fn verify(...)
| |---keygen.rs // pub fn gen_key(...)
| |---sign.rs // pub fn sign(...)
| |---mod.rs // pub mod verify; pub mod keygen; pub mod sign;
|
|--level2
| |---verify.rs // pub fn verify(...)
| |---keygen.rs // pub fn gen_key(...)
| |---sign.rs // pub fn sign(...)
| |---mod.rs // pub mod verify; pub mod keygen; pub mod sign;
字符串
根据Rust的术语,我认为我有一个crate和几个同名的模块(例如两个名为sign
的模块,派生自文件名sign.rs
)。
例如,我可以从level2 / sign.rs / sign()
的实现中以简洁但明确的方式访问level1
的sign()
函数:
level2/sign.rs:
use crate::level1;
pub fn sign() {
level1::sign();
}
型
当然,任何用户(以及example1.rs
)的整个API都是通过lib.rs
和每个文件夹的mod.rs
提供的。
examples/example1.rs:
use crate_name::*;
fn main() {
crate_name::level1::sign::sign();
crate_name::level2::sign::sign();
}
型
我的问题是:
1.是否有方法实现以下内容(省略文件名/模块名),如果有:如何实现?
[...]
fn main() {
crate_name::level1::sign();
crate_name::level2::sign();
}
型
1.像level1/sign.rs
这样的文件被称为modules
(sign
)。像level1
这样的文件夹被称为什么?它们既不是板条箱也不是模块--有术语吗?
1.我看到像level1/sign.rs
这样的文件被认为是modules
,因为mod.rs
包含一个像pub mod sign
这样的语句,而没有任何声明mod sign { ... }
。所以我假设有一个约定,默认情况下,有一个模块被称为像源文件一样。同一文件中的其他模块可以通过mod tests { ... }
引入。我理解正确吗?
1条答案
按热度按时间nbysray51#
有没有一种方法来实现以下(省略文件名/模块名)?
如果你创建的模块在你的crate的公共API中不是有意义的细分,你可以并且应该通过reexports隐藏它们。你的
level1/mod.rs
目前大概包含:字符串
它应该包含以下内容。(注意模块本身不再是公共的。)
型
或者你可以使用glob import从每个模块中重新导出所有public:
型
在设计公共模块时,我强烈建议您运行
cargo doc --open
并查看为您的库生成的文档,并考虑组织(以及随附的文档文本)是否对您的用户清晰。像
level1/sign.rs
这样的文件被称为模块(sign
)。像level1
这样的文件夹被称为什么?它们既不是板条箱也不是模块--有术语吗?它只是编译器查找
level1
模块的子模块代码的文件夹。它本身不是Rust程序的任何类型的元素。还要注意,
src/level1/mod.rs
是名为level1
的模块的源文件(您也可以将其放在src/level1.rs
中;这种样式较新,与旧样式相比,建议略加推荐,但口味各不相同,使用mod.rs
没有坏处)。我看到像
level1/sign.rs
这样的文件被认为是modules
,因为mod.rs
包含一个像pub mod sign
这样的语句,而没有任何声明mod sign { ... }
。所以我假设有一个约定,默认情况下,有一个模块被称为像源文件一样。同一文件中的其他模块可以通过mod tests { ... }
引入。我理解正确吗?我更愿意说,
src/level1/sign.rs
* 不是 * 一个模块,它是一个源代码文件;模块是items,与其他项目(如函数和类型)一样,在源代码中声明**(mod sign;
或mod sign {...}
)。磁盘上的文件布局只是编译器根据模块声明自动查找代码文件的位置,并且对于程序来说,没有比(通常)为您声明的每个模块提供不同的路径更重要的意义。将
mod
s视为crate的基本组织,将源文件布局视为如何将mod
s的代码存储在可预测位置的约定。(可以指示编译器在不同的位置查找模块的源代码-但不要这样做,因为这会使读者感到困惑,而看起来这是一个很好的选择的情况通常会以其他方式得到更好的处理。)