【问题标题】:best practice for parameters?参数的最佳实践?
【发布时间】:2011-10-13 13:31:18
【问题描述】:

如果可以的话,通常认为将参数作为指针而不是作为值传递更好吗?显然这在很大程度上取决于情况,但是当有选择时,使用指针会更好吗?

这仅仅是因为记忆的原因吗?

如果它是真的,什么是更好的通过,是指针还是引用?

【问题讨论】:

标签: c++ coding-style


【解决方案1】:

一些一般的经验法则:

如果你需要修改它,传递一个指针或一个引用。如果值可能为 null,则传递一个指针,否则传递一个引用。

如果它很大,则传递一个 const 指针或 const 引用,具体取决于 null 是否为合法值。

如果使用指针,最好使用智能指针而不是裸指针。

否则,按值传递。

【讨论】:

  • ... 一个有意的相对术语。问题是复制值是否比指向值的指针成本更高,以及它是否重要。就个人而言,超过 8 个字节左右,我倾向于传递指针或引用。
  • ... 也可能意味着“任何需要非平凡复制构造函数的东西”,尽管这通常需要“大”尺寸。
  • 我在“复制成本更高”中暗示了这一点,但应该明确。大小通常是复制成本的原因,但不是唯一的原因。
  • 传递指针/引用和常量指针/引用有什么区别?如果对象“大”,为什么首选一个?
  • @SirYakalot:如果您通常按值传递某些内容并决定通过 ptr/reference 传递它(无论出于何种原因),您宁愿通过 const 引用而不是非const 参考。这是因为当您按值传递时,该函数无法修改调用者的值副本。因此,要保持相同的语义,请传递const 引用,因为通过非const 引用传递函数可以 更改调用者的值。希望这是有道理的。
【解决方案2】:

在 C++ 中,当您按值传递时,它会调用自定义类的复制构造函数。如果您要传递向量或大型数据结构,这可能会非常昂贵。

您应该使用 const 和 reference 来不复制它并仍然保护该值。否则,对整数等较小的事物使用 value 通常是合理的。

【讨论】:

    【解决方案3】:

    最好从不传递指针。

    1. 通过 const 引用传递以避免复制成本。

    2. 如果希望函数修改原始,则通过引用传递。

    3. 否则按值传递。

    4. 指针不应在 RAW 中传递(无所有权语义)
      指针不应该放在智能指针或容器类之外。

    5. 仅当对象可能为 NULL 并且所有权未明确传递(通过大量文档)时,您才应该传递指针。

    我希望看到指针的唯一时间是当我不能使用引用时(即它可能是 NULL)并且实际上永远不会(或包裹在容器方法的深处)。

    【讨论】:

    • 应该NEVER使用never这个词。在某些情况下,您必须传递指针,尤其是当 NULL 可能是函数的有效参数时,那么 references 可能没有意义;不能使用智能指针。
    • 最佳实践并非包罗万象。因此 NEVER 是合适的。最好从不做开始,然后一旦你理解了语言,就会学习例外情况。
    • Loki:最佳实践这句话并不意味着总是。 很少个实例表明最佳实践实际上是更糟糕的实践。
    • @Nawaz:是的。因此,最好始终使用“最佳实践”,直到您了解何时不这样做。因此是最佳实践,而不是法律。
    • @Andy Thomas-Cramer:我宁愿不使用指针(但不幸的是,有时我需要这样做),但最佳实践仍然是永远不要使用它们。 :-)
    【解决方案4】:

    这取决于您传递的参数类型。如果参数大小合理(再次由您决定)低,那么您可能希望按值传递。

    对于大型结构/数组,传递pointer or reference 始终是一个好习惯。最重要的是,如果参数不应该是可修改的,那么你也可以添加const

    【讨论】:

      【解决方案5】:

      我通常通过引用(可能是常量)传递输入参数,通过指针传递输出参数。

      这样可以立即看到哪些参数是输入参数,哪些参数是输出参数(被调用者修改它们的内容)。

      当然,形成像 int、long 等的小类型我不关心引用。

      【讨论】:

      • 输入参数可以通过引用或指针传递。一个 const 限定的指针或引用表示一个输入参数。非 const 限定的指针或引用指示输出参数或 const 不正确。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-09-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多