I find it way more annoying that std::function's type erasure--but insistence that it should be copyable--means it isn't able to commit to being movable, and so then simply <i>can't</i> store move-only functions; in practice I simply <i>never</i> want to copy an std::function, yet the type is seemingly crippled to offer that ability :/. Between this issue and how it tends to require memory allocation even in cases of bounded scope, I honestly just find std::function only useful in trivial "toy" code (or where I am going out of my way to use STL for some silly reason)... I have a few type-erasing function wrappers of my own that I use in various projects, and I do live demos for the intro CS classes I help teach wherein I quickly type out new rather-fully-featured replacements, showing the iterative implementation as you need new functionality.
Since the HN username matches the twitter name, I'll bite: Is it the case that a raw function pointer is always trivially copyable?<p>I'm not super familiar with C++'s memory model, especially since they have deprecated the notion of POD and replaced it with trivially constructable.<p>My rudimentary thought process is that you can't just "move" raw functions because there is probably some assumptions made that a C++ function's call-site isn't going to move around if it isn't owned by an object. Otherwise, the runtime would have to deduce the location of the function call every time.<p>Well, on second thought, <i>is</i> there any reason why an int function ptr should be any different from an int ptr?<p>Asking as someone who has been writing C++ on-and-off for a few years for games, school, etc. but never professionally.