Don’t blindly prefer emplace_back to push_back

"emplace_back"? People actually looked at this and went "Yes, this is a good function name. I understand this perfectly."?

If you realise how it relates to "placement new" then it does kinda make sense. But yeah, not exactly beginner friendly!

Naming things is very hard. Wish there was away to learn how to do it better. Reading more to acquire new vocabulary? Learning latin? I'm not really sure.

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.

Wouldn't have that the inverse effect? - The more I know about the origin and etymology the more clever words I pick, the harder it is for the ones without that knowledge? The more trivial name might be the better one.

Something like construct_back would've maybe been a little clearer. I imagine that would have it's own issues as well though.

I quite like the name, not least because it accurately gives the impression of "something you will probably misunderstand".

Or just `place_back`! Why do they have to be so whimsical?

Maybe they're fans of why's guide to Ruby :)

Though place_back still has the connotation of 'take this thing and put it over there' that emplace_back is actually the opposite of.

Naming things really is hard.

Yeah just give everything a Latin name, your co-workers will thank you ;).

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.

Don't insist on making names as short as humanly possible. Use more words. That's all it takes.

You'd prefer something like vec.construct_then_push_back(foo, bar)? I think it's reasonable that people would want a pithier name than that, for something you're going to use constantly.

"f8" would be even shorter, but we don't use that, because it is more important that code is easy to read than quick to write.

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.

My stance: You start writing some piece of code and introduce e.g. a variable or a function. Then, half a minute later, you want to actually use it. You probably forgot which exact name you gave that thing. Instead of looking it up, try to come up with the name again (this time you're in the "user" perspective, not the "creator" one).

If you came up with the same name: Congratulations, you probably picked a good name!

If not: Think about how the two names you picked differ. What made you sway towards one or the other in the respective contexts? Is there some subtlety that you were not aware of earlier? Is the intention still the same? Maybe you even realize that what you wrote earlier doesn't fully do what you needed.

This also works on longer time scales and in reverse, of course. Occasionally I look at some older code I wrote and realize that, with a shifted frame of mind, I read/understand a function name the wrong way, even though it technically means the right thing too. Try to learn from these experiences as you make them and consider them when you're coming up with a name ("can this be misunderstood from the perspective of a user that is trying to do something that's only tangentially related?").

This had me burst out laughing. Thanks for that perspective. I guess that's one way to solve the naming problem: just make all your names super obscure as a warning to any would-be students of the dark arts.

A lot of words have latin origins though. Especially scientific jargon. Greek too.

I think they mean `std::vector::construct_back_in_place()`. 200 character line widths will no longer be enough: 400 or 500 will be more realistic. Sacrifice readability for readability.

My personal rules of naming, in order of importance are:

1. Be unique.

2. Don't be misleading.

3. Be leading.

So in this case you are nailing 2 but missing out on three which I would consider a "pretty good" name. Sure, it would be nice if it was a bit more obvious (maybe construct_in_place_back?) but at least it doesn't sound like it does something else so people know to look it up.

It means put into position. Seems perfectly reasonable

How many function calls do you put on a single line? Break those statements up!

I use this all the time to improve the name I picked in the first place.

But there is something I noticed: changing to a new name on the spot is more work.

I have to find all the previous occurrences and rename them.

I can use my editor to help, some plugins for it, or I can get the code to some parsable step and then do a refactor rename.

Notice how I had to get sidetracked here while I am trying to keep my original context in mind.

I use vim, so maybe I am missing out on fancier ways to do this quick on the spot rename? I would love to optimize this problem away.