C++:使用 '.'表达式和函数调用上的运算符

发布于 2024-10-18 14:00:26 字数 428 浏览 9 评论 0原文

我想知道像这样使用成员运算符 . 是否是一个好习惯:

someVector = (segment.getFirst() - segment.getSecond()).normalize().normalCCW();

只是为了显示我想知道的两个不同的事情,即如果使用 (expressions).member/function ()foo.getBar().getmoreBar() 符合可读性和可维护性的精神。在我学习的所有 C++ 代码和书籍中,我从未见过它以这种方式使用,但使用它却非常简单。但不想养成任何坏习惯。

可能比这更(或更不)重要的是,我还想知道以这种方式使用它是否会带来任何性能增益/损失,或者会在程序中引入错误的不可预见的陷阱。

先感谢您!

I was wondering if it is good practice to use the member operator . like this:

someVector = (segment.getFirst() - segment.getSecond()).normalize().normalCCW();

Just made that to show the two different things I was wondering, namely if using (expressions).member/function() and foo.getBar().getmoreBar() were in keeping with the spirit of readability and maintainability. In all the c++ code and books I learned from, I've never seen it used in this way, yet its intoxicatingly easy to use it as such. Don't want to develop any bad habits though.

Probably more (or less) important than that, I was also wondering if there would be any performance gains/losses by using it in this fashion, or unforeseen pitfalls that would introduce bugs into the program.

Thank you in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

﹉夏雨初晴づ 2024-10-25 14:00:26

或者不可预见的陷阱会在程序中引入错误

好吧,可能的陷阱将

  1. 更难调试。您将无法查看每个函数调用的结果,因此如果其中一个函数返回了意外的结果,您将需要将其分成更小的部分以查看发生了什么。此外,链中的任何调用都可能完全失败,因此,您可能必须再次将其分解才能找出哪个调用失败。

  2. (有时)更难阅读。链接函数调用会使代码更难阅读。这取决于具体情况,这里没有硬性规定。如果表达式有点复杂,就会使事情变得难以理解。我在阅读您的具体示例时没有任何问题。

最终取决于个人喜好。我并不努力在一条线上尽可能多地适应,并且我已经被不应该链接的地方咬住了很多次,所以我倾向于把东西分解一点。但是,对于不太可能失败的简单表达式,链接就可以了。

or unforeseen pitfalls that would introduce bugs into the program

Well, the possible pitfalls would be

  1. Harder to debug. You won't be able to view the results of each function call, so if one of them is returning something unexpected you will need to break it up into smaller segments to see what is going on. Also, any call in the chain may fail completely, so again, you may have to break it up to find out which call is failing.

  2. Harder to read (sometimes). Chaining function calls can make the code harder to read. It depends on the situation, there's no hard and fast rule here. If the expression is even somewhat complex it can make things hard to follow. I don't have any problem reading your specific example.

It ultimately comes down to personal preference. I don't strive to fit as much as possible on a single line, and I have been bitten enough times by chaining where I shouldn't that I tend to break things up a bit. However, for simple expressions which are not likely to fail, chaining is fine.

还在原地等你 2024-10-25 14:00:26

是的,这是完全可以接受的,事实上,如果您不这样做,在很多情况下将完全无法阅读。

这称为方法链。

由于您没有创建临时变量,可能会带来一些性能提升。但任何有能力的编译器都会对其进行优化。

Yes, this is perfectly acceptable and in fact would be completely unreadable in a lot of contexts if you were to NOT do this.

It's called method chaining.

There MIGHT be some performance gain in that you're not creating temporary variables. But any competent compiler will optimise it anyway.

心意如水 2024-10-25 14:00:26

按照您展示的方式使用它是完全有效的。它用于 C++ 中描述的命名参数习惯用法例如常见问题解答精简版。

不总是使用它的一个原因是,当您出于性能原因必须存储中间结果时(如果归一化成本高昂并且必须多次使用它,则最好将结果存储在变量中)或可读性。

我的2c

it is perfectly valid to use it the way you showed. It is used in the named parameter idiom described in C++ faq lite for example.

One reason it is not always used is when you have to store intermediate result for performance reasons (if normalize is costly and you have to use it more than one time, it is better to store the result in a variable) or readability.

my2c

怪异←思 2024-10-25 14:00:26

使用变量来保存中间结果有时可以增强可读性,特别是在使用良好的变量名称时。过多的链接会让人很难理解正在发生的事情。您必须运用自己的判断来决定是否值得使用变量来分解链条。你上面举的例子对我来说并不过分。如果启用优化,性能应该不会有太大差异。

Using a variable to hold intermediate results can sometimes enhance readability, especially if you use good variable names. Excessive chaining can make it hard to understand what is happening. You have to use your judgement to decide if it's worthwhile to break down chains using variables. The example you present above is not excessive to me. Performance shouldn't differ much one way or the other if you enable optimization.

深府石板幽径 2024-10-25 14:00:26
someVector = (segment.getFirst() - segment.getSecond()).normalize().normalCCW();

不是你问题的答案,但我应该告诉你
表达式 (segment.getFirst() - segment.getSecond()) 的行为未按照 C++ 标准明确定义。标准未指定每个操作数的计算顺序!

另请参阅此相关主题:此代码定义良好吗?

someVector = (segment.getFirst() - segment.getSecond()).normalize().normalCCW();

Not an answer to your question, but I should tell you that
the behavior of the expression (segment.getFirst() - segment.getSecond()) is not well-defined as per the C++ Standard. The order in which each operand is evaluated is unspecified by the Standard!

Also, see this related topic : Is this code well-defined?

捎一片雪花 2024-10-25 14:00:26

我想你正在做的事情可读性较差,但另一方面,太多的临时变量也可能变得不可读。

就性能而言,我确信创建临时变量时会产生一些开销,但编译器可以对其进行优化。

I suppose what you are doing is less readable, however on the other hand, too many temporary variables can also become unreadable.

As far performance I'm sure there is a little overhead when making temporary variables but the compiler could optimize that out.

箹锭⒈辈孓 2024-10-25 14:00:26

以这种方式使用它并没有什么大问题——一些 API 从方法链中受益匪浅。另外,创建一个变量然后只使用一次是一种误导。当有人阅读下一行时,他们不必考虑您现在没有保留的所有变量。

There's no big problem with using it in this way- some APIs benefit greatly from method chaining. Plus, it's misleading to create a variable, and then only use it once. When someone reads the next line, they don't have to think about all those variables that you now didn't keep.

就是爱搞怪 2024-10-25 14:00:26

这取决于你在做什么。

为了便于阅读,您应该尝试使用中间变量。
将计算结果分配给指针,然后使用它们。

It depends of what you're doing.

For readability you should try to use intermediate variables.
Assign calculation results to pointers, and then use them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文