Should stack_alloc use emplace_back instead of push_back?

math

#1

Was watching the below youtube video and thought, "Oh don’t we use push_back in stack_alloc? Should we use emplace_back (with move()?)**

Bob used it in his continuation based autodiff post and mentioned it in the moving to C++11 post.

Looking at the stack_alloc code it looks like emplace_back would be fine?

If no one has objections I can try it out and run the performance tests over it this week.

Note: idt what he is talking about in the video is 100% relevant, but it’s interesting and made me look at whether we were using push_back or emplace_back. It starts at the point that I thought was relevant.

**TL;DR for push_back vs. emplace_back is summarized here and essentially avoids a temporary copy when moving an object into a vector.


#2

stack_alloc: 73

  std::vector<char*> blocks_;  // storage for blocks,
                               // may be bigger than cur_block_
  std::vector<size_t> sizes_;  // could store initial & shift for others

Here only pointers are used, no objects. I doubt it will have any benefit.
See also the answer from visitor in the following post:


#3

Thanks, @andre.pfeuffer — I think this is right.

There are lots of places where we could use emplace_back, and more generally employ move semantics to reduce copying in other places.


#4

Cool good to know! I’ll take a look this weekend