这是避免不断创建对象的好习惯吗？
早上好，
假设我有一个类 ClassA，一个运算符 +，它对两个 ClassA 类型的对象进行求和，这是来自 的隐式转换int到ClassA，并且我想重载运算符++...假设+的代码相当长，但是 ClassA 和 1 的总和是它的一个非常特殊的情况，哪个选项更好？
- 使用
+和已定义的隐式转换实现++。 - 重复部分代码，仅添加
1即可简化很多操作。
我的想法是（2）更好，因为它节省了通过隐式转换创建新的 ClassA 对象的时间，如果使用 ++ 运算符，这将非常有用，例如，在 for 循环中。另外，速度也是必须的。
非常感谢。
Good morning,
Say I have a class ClassA, an operator + which sums up two objects of type ClassA, an implicit casting from intto ClassA, and that I want to overload the operator ++... Supposing the code for + is rather long, but that the sum of a ClassA and 1 is a very particular case of it, which option is better?
- Implement
++using+and the implicit casting already defined. - Repeat part of the code which simplifies alot when adding just
1.
My idea is that (2) is better since it saves the creation of a new ClassA object by the implicit casting, which can be quite useful if the ++ operator is used, for example, in a for cycle. Also, speed is a must.
Thank you very much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你已经回答了你自己的问题。如果速度是必须的，那么请选择第二个更快的选项（最好对其进行基准测试以确保它确实明显更快）。
否则，请选择第一个选项，因为代码越少越好（并保持 DRY 双重效果）。更少的代码意味着更少的潜在错误、更少的维护、更少的编写和更少的阅读。如果代码很大程度上重复了另一部分代码，那么您在进行更改时必须保持两者同步——这会带来麻烦，因为很容易忘记更新其中一个（即使您总是记得更新）对两个地方的更改，因为它们并不完全相同，因此可能正确更新一个部分而错误地更新另一部分）。
在做出最终决定之前，请确保速度确实是必须的——您不希望过早优化。
You've answered your own question. If speed is a must, then go with the second, faster option (it's a good idea to benchmark it to make sure it really is significantly faster though).
Otherwise, go with the first option since less code is better (and staying DRY doubly-so). Less code means less potential bugs, less to maintain, less to write, and less to read. If the code largely duplicates another section of code, then you'd have to keep the two in sync as you make changes -- this would be inviting trouble, as it's easy to forget to update one (and even if you always remember to make changes to both places, since they're not exactly identical it's possible to correctly update one section and incorrectly update the other).
Make sure speed really is a must though before making your final decision -- you don't want premature optimization.
无论哪种方式都是可以接受的。听起来第二种方法是你已经倾向于的，所以尝试一下。事实上，尝试两种方法并测量增加一百万倍所需的时间。基准测试始终是做出这些决策的方法。
如果您之前没有做过任何基准测试，最简单的方法是创建一个 System.Diagnostics.Stopwatch 并围绕相关代码启动/停止它。然后您可以将经过的时间写入控制台。
Either way is acceptable. It sounds like the second way is what you're already leaning towards, so try it. In fact, try it both ways and measure the time it takes to increment a million times. Benchmarking is always the way to make these decisions.
In case you haven't done any benchmarking before, the simplest way is to create a System.Diagnostics.Stopwatch and start/stop it around the relevant code. You can then write the elapsed time to a console.
我的观点是，如果 +1 是一个真正的特殊情况，要简单得多，请执行特殊的 ++ 实现。如果您想保持代码较小，您可以随时将其注释掉并将其引用到 + 1。
否则，很容易忘记这个特殊的优化 6 个月。当您尝试优化时。
过早优化是指您在知道如何优化之前进行优化，而不是在您有明确的理由时进行优化。然而，如何划清界限却很困难。您需要确定 ++ 代码要简单多少才能考虑将其放入。
My opinion is that if +1 is a real special case that is much simpler, do the special ++ implementation. You can always comment it out and refer it to + 1 if you want to keep your code small.
Otherwise, it will be too easy to forget about this special optimization 6 mo. down the road when you are trying to optimize.
Premature optimization refers to the fact that you are optimizing before you know how to, not when you have a clear rationale to do so. How to draw the line is difficult, however; you'd need to decide how much simpler the ++ code is in order to consider putting it in.