当前位置: 首页 > 知识库问答 >
问题:

为什么不鼓励接受对String的引用(

郎子平
2023-03-14

我写了一些带

fn awesome_greeting(name: &String) {
    println!("Wow, you are awesome, {}!", name);
}

我还编写了代码,其中包含对Vec框的引用:

fn total_price(prices: &Vec<i32>) -> i32 {
    prices.iter().sum()
}

fn is_even(value: &Box<i32>) -> bool {
    **value % 2 == 0
}

然而,我收到了一些反馈,认为这样做不是一个好主意。为什么不呢?


共有2个答案

呼延修然
2023-03-14

除了Shepmaster的回答之外,接受

如果您有:

fn awesome_greeting(name: &String) {
    println!("Wow, you are awesome, {}!", name);
}

但是你需要用奶牛来称呼它

let c: Cow<str> = Cow::from("hello");
// Allocate an owned String from a str reference and then makes a reference to it anyway!
awesome_greeting(&c.to_string());

当您将参数类型更改为

let c: Cow<str> = Cow::from("hello");
// Just pass the same reference along
awesome_greeting(&c);

let c: Cow<str> = Cow::from(String::from("hello"));
// Pass a reference to the owned string that you already have
awesome_greeting(&c);

接受

龙华翰
2023-03-14

TL; DR:可以改为使用

>

接受

awesome_greeting(&String::from("Anna"));
total_price(&vec![42, 13, 1337])
is_even(&Box::new(42))

另一个性能考虑因素是

相反,您应该接受字符串片段(

fn awesome_greeting(name: &str) {
    println!("Wow, you are awesome, {}!", name);
}
fn total_price(prices: &[i32]) -> i32 {
    prices.iter().sum()
}
fn is_even(value: &i32) -> bool {
    *value % 2 == 0
}

现在,您可以使用更广泛的类型集调用这些方法。例如,可以使用字符串文本(“Anna”)或分配的字符串来调用awesome\u greeting<代码>总价可以通过对数组(

如果要添加或删除字符串Vec中的项目

fn add_greeting_target(greeting: &mut String) {
    greeting.push_str("world!");
}
fn add_candy_prices(prices: &mut Vec<i32>) {
    prices.push(5);
    prices.push(25);
}

特别是对于切片,您也可以接受

fn reset_first_price(prices: &mut [i32]) {
    prices[0] = 0;
}
fn lowercase_first_ascii_character(s: &mut str) {
    if let Some(f) = s.get_mut(0..1) {
        f.make_ascii_lowercase();
    }
}

 类似资料:
  • 大多数在线来源都表明您可以静态链接glibc,但不鼓励这样做;例如centos包repo: glibc静态包包含用于静态链接的C库静态库。你不需要这些,除非你静态链接,这是非常不鼓励的。 这些消息来源很少(或从未)说明为什么这是个坏主意。

  • Django Rest框架序列化程序不调用。给出的解释是,这导致了Django Rest Framework 3.0发行说明中的“更清晰的关注点分离”: 此更改还意味着我们不再使用方法,但在序列化程序上显式执行所有验证。这提供了更清晰的分离,并确保ModelSerializer类上没有自动验证行为,而这些行为也不能轻松地复制到常规序列化程序类上。 但是DjangoRest框架的作者试图分离哪些问题

  • 问题内容: 这是来自Hibernate的官方教程: 还有一个替代声明,该声明允许使用组合键访问旧数据。强烈建议不要将其用于其他任何用途。 为什么不鼓励使用复合键?我正在考虑使用一个三列表,其中所有列都是外键,并且一起形成一个主键,这在我的模型中是有意义的关系。我不明白为什么这是一个坏主意,特别是我将在它们上使用索引。 有什么选择?创建一个额外的自动生成的列并将其用作主键?无论如何,我仍然需要查询我

  • 问题内容: Model.clean验证模型序列化器时,Django Rest Framework序列化器不会调用。给出的解释是,这导致了Django Rest Framework 3.0发行说明中的 “更清晰的关注点分离” : ModelSerializer验证和ModelForm之间的差异。 此更改还意味着我们不再.full_clean()在模型实例上使用该方法,而是在序列化程序上显式执行所有验

  • 问题内容: 关于Java EE开发的第一件事是,我不应该在Java EE容器中生成自己的线程。但是当我考虑它时,我不知道原因。 您能清楚地解释为什么不鼓励这样做吗? 我确信大多数企业应用程序都需要某种异步作业,例如邮件守护程序,空闲会话,清理作业等。 因此,如果确实不应该产生线程,那么在需要时正确的方法是什么? 问题答案: 不建议这样做,因为环境中的所有资源都应由服务器进行管理,并可能由服务器进行