if(shared_ptr<GuiContextMenu> subMenu = items[j].subMenu.lock()) {
subMenu->setVisible(false);
}
//subMenu is no longer in scope
我假设 subMenu 是一个 weak_ptr，在这种情况下，您的第二种方法会创建两个临时变量，这可能会或可能不会成为问题。您的第一个方法将变量添加到比需要更广泛的范围。就我个人而言，我尝试避免在 if 语句中进行赋值，但这是我认为它比替代方案更有用的少数情况之一。
An alternative method:
if(shared_ptr<GuiContextMenu> subMenu = items[j].subMenu.lock()) {
subMenu->setVisible(false);
}
//subMenu is no longer in scope
I'm assuming subMenu is a weak_ptr, in which case your second method creates two temporaries, which might or might not be an issue. And your first method adds a variable to a wider scope than it needs to. Personally, I try to avoid assignments within if statements, but this is one of the few cases where I feel its more useful than the alternatives.
In this particular case, you really should use the version with the temporary variable. The reason is not performance, but correctness - basically, you are not guaranteed that the two x.lock() calls return the same value (eg. if another thread releases the last strong reference on the object just between the two calls). By holding the strong reference in the temporary variable, you ensure it won't go away.
Other than that:
the compilers usually can't optimise out function calls, unless they are provably side-effect free (this is hard to do, but attributes may help) or inlined. In this case, the call has side-effects.
using temporaries can lead to shorter, more readable and more maintainable programs (eg. in case of error, you fix it in one place)
I think you're correct about either choice being no different after optimisation.
Personally, I would declare a new variable if it makes the code more readable, such as when you're chaining calls, or putting function calls inside function calls. As long as it's maintainable and the code achieves the same effect at no speed difference, it all boils down to readable code.
Edit:
mmyers bought up a good comment. Yes, be careful about calling lock() twice, as opposed to just once. They will have different effects depending on your implementation.
When the return value is anything other that a boolean, assigning it to an intermediate variable can often simplify debugging. For example, if you step over the following:
if( fn() > 0 ) ...
all you will know after the fact was that the function returned a value either less than zero, or zero or more. Even if the return value were incorrect, the code may still appear to work. Assigning it to a variable that can be inspected in your debugger will allow you to determine whether the return value was expected.
When the return is boolean, the actual value is entirely implicit by the code flow, so it is less critical; however under code maintenance you may find later you need that result, so you may decide to make it a habit in any case.
Even where the return value is boolean, another issue to consider is whether the function has required side-effects, and whether this may be affected by short-circuit evaluation. For example in the statement:
if( isValid && fn() ) ...
the function will never be called is isValid is false.
The circumstances under which the code could be broken under maintenance by the unwary programmer (and it is often the less experienced programmers that get the maintenance tasks) are many, and probably best avoided.
In this specific example, I think it depends on what lock() does. Is the function expensive? Could it return different things each time the function is called (could it return a pointer the first time and NULL the second time)? Is there another thread running that could interleave between the two calls to lock()?
For this example, you need to understand the behavior of lock() and the rest of your code to make an intelligent decision.
I prefer the first one most of the time because it makes the code more clear and easy to read, therefore less error prone. For example, you forgot a parenthesis on that second example :) In this case, actually, I'd probably do what you did in the second example, however if I needed to use that submenu more than a few times I'd go with the first one to make the code easier to read. As for performance, I thing any sane compiler would be able to optimize that (which is probably why you saw no difference in performance).
Also, as mmyers pointed out, that also depends on what lock() does. In general, if it's a simple getter method or something like that, you'll be fine.
Whatever YOU prefer. For me, it depends on how much I'll use it; for two lines, I might just write it out both times, whereas I create a variable if I use it more. However, YOU are the one who will most likely have to maintain this code and continue looking at it, so use whatever works for you. Of course, if you're at a company with a coding guideline, follow it.
I think the preferred style is whatever style you think makes your code more readable and maintainable. If you're a team of more than one, the only other consideration is that it's generally a good idea for everyone to adopt the same style, again for readability and ease of maintenance.
In this case I think you should use the temporary. Even if you know the implementation to .lock() is inexpensive, that can change. If you don't need to call lock() twice, don't. The value here is that it decouples your code from the implementation of lock(). And that's a good thing generally.
发布评论
评论（10）
另一种方法：
我假设
subMenu是一个weak_ptr，在这种情况下，您的第二种方法会创建两个临时变量，这可能会或可能不会成为问题。您的第一个方法将变量添加到比需要更广泛的范围。就我个人而言，我尝试避免在if语句中进行赋值，但这是我认为它比替代方案更有用的少数情况之一。An alternative method:
I'm assuming
subMenuis aweak_ptr, in which case your second method creates two temporaries, which might or might not be an issue. And your first method adds a variable to a wider scope than it needs to. Personally, I try to avoid assignments withinifstatements, but this is one of the few cases where I feel its more useful than the alternatives.在这种特殊情况中，您确实应该使用带有临时变量的版本。原因不是性能，而是正确性 - 基本上，您不能保证两个 x.lock() 调用返回相同的值（例如，如果另一个线程释放了对象上的最后一个强引用）两次调用之间）。通过在临时变量中保留强引用，可以确保它不会消失。
除此之外：
编译器通常无法优化函数调用，除非它们被证明是无副作用的（这很难做到，但属性可能会有所帮助）或内联。在这种情况下，调用会产生副作用。
使用临时程序可以生成更短、更具可读性和更易于维护的程序（例如，如果出现错误，您可以在一个地方修复它）
In this particular case, you really should use the version with the temporary variable. The reason is not performance, but correctness - basically, you are not guaranteed that the two
x.lock()calls return the same value (eg. if another thread releases the last strong reference on the object just between the two calls). By holding the strong reference in the temporary variable, you ensure it won't go away.Other than that:
the compilers usually can't optimise out function calls, unless they are provably side-effect free (this is hard to do, but attributes may help) or inlined. In this case, the call has side-effects.
using temporaries can lead to shorter, more readable and more maintainable programs (eg. in case of error, you fix it in one place)
我认为您的说法是正确的，优化后这两种选择都没有什么不同。
就我个人而言，如果它使代码更具可读性，我会声明一个新变量，例如当您链接调用或将函数调用放在函数调用中时。只要它是可维护的，并且代码在没有速度差异的情况下达到相同的效果，那么这一切都归结为可读的代码。
编辑：
mmyers 买了一个很好的评论。是的，调用
lock()两次要小心，而不是只调用一次。根据您的实施，它们将产生不同的效果。I think you're correct about either choice being no different after optimisation.
Personally, I would declare a new variable if it makes the code more readable, such as when you're chaining calls, or putting function calls inside function calls. As long as it's maintainable and the code achieves the same effect at no speed difference, it all boils down to readable code.
Edit:
mmyers bought up a good comment. Yes, be careful about calling
lock()twice, as opposed to just once. They will have different effects depending on your implementation.选择基本上取决于您，但您应该注意的基本事项是可维护性。
The choice is essentially up to you, but the basic thing you should look out for is maintainability.
当返回值不是布尔值时，将其分配给中间变量通常可以简化调试。例如，如果您跳过以下内容：
事后您将知道该函数返回的值要么小于零，要么为零或更大。即使返回值不正确，代码看起来仍然可以工作。将其分配给可以在调试器中检查的变量将允许您确定返回值是否是预期的。
当返回值为布尔值时，实际值完全由代码流隐式表示，因此不太重要；然而，在代码维护过程中，您可能会发现稍后您需要该结果，因此您可能决定无论如何都要养成这种习惯。
即使返回值是布尔值，另一个需要考虑的问题是该函数是否具有所需的副作用，以及这是否可能受到短路评估的影响。例如在声明中：
isValid 为 false 时函数将永远不会被调用。
在许多情况下，粗心的程序员（通常是经验不足的程序员承担维护任务）在维护时可能会破坏代码，最好避免这种情况。
When the return value is anything other that a boolean, assigning it to an intermediate variable can often simplify debugging. For example, if you step over the following:
all you will know after the fact was that the function returned a value either less than zero, or zero or more. Even if the return value were incorrect, the code may still appear to work. Assigning it to a variable that can be inspected in your debugger will allow you to determine whether the return value was expected.
When the return is boolean, the actual value is entirely implicit by the code flow, so it is less critical; however under code maintenance you may find later you need that result, so you may decide to make it a habit in any case.
Even where the return value is boolean, another issue to consider is whether the function has required side-effects, and whether this may be affected by short-circuit evaluation. For example in the statement:
the function will never be called is isValid is false.
The circumstances under which the code could be broken under maintenance by the unwary programmer (and it is often the less experienced programmers that get the maintenance tasks) are many, and probably best avoided.
在这个具体示例中，我认为这取决于
lock()的作用。功能贵吗？每次调用函数时是否会返回不同的内容（是否可以第一次返回指针，第二次返回 NULL）？是否有另一个正在运行的线程可以在两次调用lock()之间交错？对于此示例，您需要了解
lock()的行为以及代码的其余部分才能做出明智的决定。In this specific example, I think it depends on what
lock()does. Is the function expensive? Could it return different things each time the function is called (could it return a pointer the first time and NULL the second time)? Is there another thread running that could interleave between the two calls tolock()?For this example, you need to understand the behavior of
lock()and the rest of your code to make an intelligent decision.大多数时候我更喜欢第一个，因为它使代码更清晰易读，因此更不容易出错。例如，您忘记了第二个示例中的括号:)
实际上，在这种情况下，我可能会执行您在第二个示例中所做的操作，但是如果我需要多次使用该子菜单，我会使用第一个子菜单以使代码更易于阅读。至于性能，我认为任何理智的编译器都能够对其进行优化（这可能就是您在性能上没有看到差异的原因）。
另外，正如 mmyers 指出的那样，这还取决于 lock() 的作用。一般来说，如果它是一个简单的 getter 方法或类似的方法，那就没问题了。
I prefer the first one most of the time because it makes the code more clear and easy to read, therefore less error prone. For example, you forgot a parenthesis on that second example :)
In this case, actually, I'd probably do what you did in the second example, however if I needed to use that submenu more than a few times I'd go with the first one to make the code easier to read. As for performance, I thing any sane compiler would be able to optimize that (which is probably why you saw no difference in performance).
Also, as mmyers pointed out, that also depends on what lock() does. In general, if it's a simple getter method or something like that, you'll be fine.
无论您喜欢什么。对我来说，这取决于我使用它的程度；对于两行，我可能会两次都写出来，而如果我更多地使用它，我会创建一个变量。然而，您很可能需要维护此代码并继续查看它，因此请使用对您有用的任何东西。当然，如果您所在的公司有编码指南，请遵循它。
Whatever YOU prefer. For me, it depends on how much I'll use it; for two lines, I might just write it out both times, whereas I create a variable if I use it more. However, YOU are the one who will most likely have to maintain this code and continue looking at it, so use whatever works for you. Of course, if you're at a company with a coding guideline, follow it.
我认为首选风格是您认为使代码更具可读性和可维护性的任何风格。如果您是一个多人团队，唯一的其他考虑因素是每个人都采用相同的风格通常是一个好主意，同样是为了可读性和易于维护。
I think the preferred style is whatever style you think makes your code more readable and maintainable. If you're a team of more than one, the only other consideration is that it's generally a good idea for everyone to adopt the same style, again for readability and ease of maintenance.
在这种情况下，我认为你应该使用临时的。即使您知道 .lock() 的实现成本低廉，这种情况也可能会改变。如果您不需要调用 lock() 两次，就不要调用。这里的价值在于它将代码与 lock() 的实现解耦。一般来说，这是一件好事。
In this case I think you should use the temporary. Even if you know the implementation to .lock() is inexpensive, that can change. If you don't need to call lock() twice, don't. The value here is that it decouples your code from the implementation of lock(). And that's a good thing generally.