Speaker: Odin Holmes

Audience level: Intermediate | Advanced

Working in the embedded domain where 'special cases' are the norm I often find myself fighting with customization capabilities and 'canned' (non-customizable) abstractions. std::string often has a small buffer for small string optimization, std::function has something similar, why can't I set the size of that buffer, or more radically why can't I just stick that same buffer in a std::vector for a 'small vector optimization'. While we're at it why can't I take .at() out of std::vectors public interface and call some user-defined function on out of memory, maybe I turned off exceptions but still want to handle errors properly. Maybe I want a std::deque interface but have a fixed sized ring buffer under the hood. Those following the SG14 will notice I am ticking off proposals, the problem with these proposals is that the mostly follow a common pattern: "I need X without Y" or "I need X to have Y" and there are many many combinations of X and Y. Why do I have to pay for atomic ref counting in a shared_pointer in a single threaded use case? We could go on all day. In this talk we will explore the feasibility of building classes from composable pieces, some concrete proof of concepts as well as the library infrastructure needed for this task