5 ms·

Don’t blindly prefer emplace_back to push_back* *when using it incorrectly. The premise of of emplace_back is that you use it for calling the constructor of th

Don’t blindly prefer emplace_back to push_back* *when using it incorrectly. The premise of of emplace_back is that you use it for calling the constructor of the object in place. Obviously it won't help you if you call a copy constructor instead. I find this article a bit pointless. Clang's suggestion was spot-on and emplace_back would have (potentially) helped if the suggestion was actually followed correctly.

xKingfisher 6y ago
It's not bad advice. I see many code reviews that use emplace_back because it's 'faster'. Though I think the abseil article does a better job of explaining why: https://abseil.io/tips/112 https://abseil.io/tips/112 [Googler; unaffiliated with Abseil(sadly)]
pdpi 6y ago
Hence “blindly”. The blog post was a detailed, less sanctimonious version of your comment.
- TonyTrapp 6y ago
  But then you could write a blog post about pretty much every API misuse ever, which doesn't really seem very constructive to me. But okay, maybe it's more obvious when having worked with pre-C++11 code, where you would have killed for something like emplace_back. If you are new to the language and only know modern C++, you probably don't think much about why emplace_back exists in addition to push_back, and why it can be faster.
  - xKingfisher 6y ago
    Given the whole scanf/strlen thing going on, more blog posts about API pitfalls wouldn't necessarily be a bad thing. And that is basically the premise of the Abseil Tip of the week series, which are an incredible resource for learning how to work with modern C++.
  - pjmlp 6y ago
    Given that some schools still teach C++ with Turbo C++ for MS-DOS, one cannot expect that everyone is up to date with CppCon C++Now talks.
- IshKebab 6y ago
  Yeah but the title sounds like "you shouldn't just always use emplace_back instead of push_back" but the actual content is "you shouldn't use emplace_back completely incorrectly because you don't know what it is". The only actual argument against blindly using emplace_back everywhere is that it has worse compile time in a deliberately pathological microbenchmark. Not convincing, though it is interesting.
beeforpork 6y ago
Actually, I am not so happy with clang-tidy: its first advice was spot-in, yes. But it should have thrown the exact same advice after the student incorrectly applied the first advised patch (by not removing the 'Widget(...)' constructor call).
- shawnz 6y ago
  Wouldn't that have changed the semantics (since you're not calling the copy constructor anymore?) The student accidentally changed the semantics by adding the extra call to the copy contstructor, and therefore Clang didn't know anymore that it could be removed
  - CJefferson 6y ago
    In that case, push_back to emplace_back changed the semantics (as construct + push_back made a move construction, whereas emplace_back did not).
    - shawnz 6y ago
      Good point, it doesn't seem to be any bigger of a change than the original suggestion. Perhaps they mistakenly thought nobody would call emplace_back in that way by accident.
  - oleganza 6y ago
    The warning was not explicit enough to ask you to remove the constructor as well as changing the method name. If it called for "hey, you can remove the constructor and emplace_back would automagically call it for you in place!" and then checked that the constructor is not spelled out there, then there would not be such issue and the tool would be 100% helpful.
    - shawnz 6y ago
      It did ask to remove the constructor as well as changing the method (note which parts are covered by tildes). My question is, after having incorrectly only done one of those things, how could it have known that the user was only halfway though a two-part operation and didn't actually mean for it to be that way? Clang doesn't know how the code was in the past.
MaxBarraclough 6y ago
The article goes even further than that: When all else is equal, prefer push_back to emplace_back. It still shows the example of using emplace_back with a pre-existing object, which as you say, isn't the point of emplace_back. It also states that it's more work for the compiler, stating that the template resolution seems more complex, and suggesting it's likely to bloat compile times. That's a more persuasive point (hard numbers are provided at the end of the article), I wonder if more work has been done on this. The author seems to be an advanced C++ programmer, but doesn't seem to properly acknowledge that, as you say, The premise of of emplace_back is that you use it for calling the constructor of the object in place. The only instance of proper use of emplace_back is in widgets.emplace_back(foo, bar, baz); I was surprised to see no follow-up for this example: auto w = Widget(1,2,3); widgets.emplace_back(w); // Fixed? Nope! No mention of the obvious fix: widgets.emplace_back(1,2,3); I don't mean to 'pile on', but, a pet peeve of mine: emplace_back is not magic C++11 pixie dust. This isn't saying anything. You could say garbage collection isn't magic, or error-correcting codes aren't magic, or sound type systems aren't magic. To say that something isn't magic is an empty statement, especially when it's something like emplace_back which introduces an important new ability.
- Sebb767 6y ago
  > To say that something isn't magic is an empty statement I think this is said to express "simply replacing that function call/method/... without changing your calls/methods/coding style is not going to magically solve your problems". Which is true in the push_back/emplace_back case (you need to adjust your call). GC, on the other hand, is magic pixie dust, if my definition is correct ;)
  - MaxBarraclough 6y ago
    > I think this is said to express "simply replacing that function call/method/... without changing your calls/methods/coding style is not going to magically solve your problems" I agree, but you're doing all the work in conjuring this interpretation. Saying it's not magic doesn't say anything substantial. If it were possible to mechanically replace all references to push_back by emplace_back for an easy performance boost, then we wouldn't need emplace_back to be its own member function, it would just be a compiler optimisation. You have to make shallow and localised changes to make proper use of emplace_back, but isn't that the best we can hope for? Far easier than parallelism, say, where sweeping architectural changes may be necessary.

xKingfisher 6y ago

It's not bad advice. I see many code reviews that use emplace_back because it's 'faster'. Though I think the abseil article does a better job of explaining why: https://abseil.io/tips/112 https://abseil.io/tips/112 [Googler; unaffiliated with Abseil(sadly)]

pdpi 6y ago

Hence “blindly”. The blog post was a detailed, less sanctimonious version of your comment.

TonyTrapp 6y ago
But then you could write a blog post about pretty much every API misuse ever, which doesn't really seem very constructive to me. But okay, maybe it's more obvious when having worked with pre-C++11 code, where you would have killed for something like emplace_back. If you are new to the language and only know modern C++, you probably don't think much about why emplace_back exists in addition to push_back, and why it can be faster.
- xKingfisher 6y ago
  Given the whole scanf/strlen thing going on, more blog posts about API pitfalls wouldn't necessarily be a bad thing. And that is basically the premise of the Abseil Tip of the week series, which are an incredible resource for learning how to work with modern C++.
- pjmlp 6y ago
  Given that some schools still teach C++ with Turbo C++ for MS-DOS, one cannot expect that everyone is up to date with CppCon C++Now talks.
IshKebab 6y ago
Yeah but the title sounds like "you shouldn't just always use emplace_back instead of push_back" but the actual content is "you shouldn't use emplace_back completely incorrectly because you don't know what it is". The only actual argument against blindly using emplace_back everywhere is that it has worse compile time in a deliberately pathological microbenchmark. Not convincing, though it is interesting.

beeforpork 6y ago

Actually, I am not so happy with clang-tidy: its first advice was spot-in, yes. But it should have thrown the exact same advice after the student incorrectly applied the first advised patch (by not removing the 'Widget(...)' constructor call).

shawnz 6y ago
Wouldn't that have changed the semantics (since you're not calling the copy constructor anymore?) The student accidentally changed the semantics by adding the extra call to the copy contstructor, and therefore Clang didn't know anymore that it could be removed
- CJefferson 6y ago
  In that case, push_back to emplace_back changed the semantics (as construct + push_back made a move construction, whereas emplace_back did not).
  - shawnz 6y ago
    Good point, it doesn't seem to be any bigger of a change than the original suggestion. Perhaps they mistakenly thought nobody would call emplace_back in that way by accident.
- oleganza 6y ago
  The warning was not explicit enough to ask you to remove the constructor as well as changing the method name. If it called for "hey, you can remove the constructor and emplace_back would automagically call it for you in place!" and then checked that the constructor is not spelled out there, then there would not be such issue and the tool would be 100% helpful.
  - shawnz 6y ago
    It did ask to remove the constructor as well as changing the method (note which parts are covered by tildes). My question is, after having incorrectly only done one of those things, how could it have known that the user was only halfway though a two-part operation and didn't actually mean for it to be that way? Clang doesn't know how the code was in the past.

MaxBarraclough 6y ago

The article goes even further than that: When all else is equal, prefer push_back to emplace_back. It still shows the example of using emplace_back with a pre-existing object, which as you say, isn't the point of emplace_back. It also states that it's more work for the compiler, stating that the template resolution seems more complex, and suggesting it's likely to bloat compile times. That's a more persuasive point (hard numbers are provided at the end of the article), I wonder if more work has been done on this. The author seems to be an advanced C++ programmer, but doesn't seem to properly acknowledge that, as you say, The premise of of emplace_back is that you use it for calling the constructor of the object in place. The only instance of proper use of emplace_back is in widgets.emplace_back(foo, bar, baz); I was surprised to see no follow-up for this example: auto w = Widget(1,2,3); widgets.emplace_back(w); // Fixed? Nope! No mention of the obvious fix: widgets.emplace_back(1,2,3); I don't mean to 'pile on', but, a pet peeve of mine: emplace_back is not magic C++11 pixie dust. This isn't saying anything. You could say garbage collection isn't magic, or error-correcting codes aren't magic, or sound type systems aren't magic. To say that something isn't magic is an empty statement, especially when it's something like emplace_back which introduces an important new ability.

Sebb767 6y ago
> To say that something isn't magic is an empty statement I think this is said to express "simply replacing that function call/method/... without changing your calls/methods/coding style is not going to magically solve your problems". Which is true in the push_back/emplace_back case (you need to adjust your call). GC, on the other hand, is magic pixie dust, if my definition is correct ;)
- MaxBarraclough 6y ago
  > I think this is said to express "simply replacing that function call/method/... without changing your calls/methods/coding style is not going to magically solve your problems" I agree, but you're doing all the work in conjuring this interpretation. Saying it's not magic doesn't say anything substantial. If it were possible to mechanically replace all references to push_back by emplace_back for an easy performance boost, then we wouldn't need emplace_back to be its own member function, it would just be a compiler optimisation. You have to make shallow and localised changes to make proper use of emplace_back, but isn't that the best we can hope for? Far easier than parallelism, say, where sweeping architectural changes may be necessary.