←back to thread

Don’t blindly prefer emplace_back to push_back

(quuxplusone.github.io)
178 points todsacerdoti | 1 comments | 04 Mar 21 08:02 UTC | HN request time: 0s | source
Show context
user-the-name ◴[04 Mar 21 09:16 UTC] No.26340320[source]▶
"emplace_back"? People actually looked at this and went "Yes, this is a good function name. I understand this perfectly."?
replies(5): >>26340335 #>>26340345 #>>26340374 #>>26340547 #>>26343435 #
dmurray ◴[04 Mar 21 09:25 UTC] No.26340374[source]▶
All the simple names and most of the syntax were taken in C++98. This is one of the problems with backwards compatibility: even if everyone migrates to the new standard on its first day, so you never actually have to target the old compiler, the simplest way to do things will often be the old way.

Also, in mitigation, it's not a special-purpose word for appending to vectors. They introduced "emplace" to other STL data structures at the same time, with the equivalent semantics, so it's a word you only have to learn once.

replies(1): >>26340944 #
user-the-name ◴[04 Mar 21 10:58 UTC] No.26340944[source]▶
I mean, this is entirely a self-inflicted problem. If you'd just use a few more words in the name, none of this would be an issue.

There's nothing wrong with longer function names. They make code a lot easier to read.

replies(2): >>26341110 #>>26341149 #
1. MauranKilom ◴[04 Mar 21 11:33 UTC] No.26341149{3}[source]▶
Actually, for frequently used standard library functionality, I would very much object to introducing overhead for educational purposes at every single call site.

It's a tradeoff, of course, but if the user code becomes unreadable because the function names are verbose (so you constantly have to wrap lines and cut through the visual noise to see the actually meaningful part of the code), just to make sure people don't misunderstand basic functionality... that's not the tradeoff I would like.