Function or class design in library API for efficient object reuse

Question

I am currently building a library in C++11, where I spent a lot of time trying to design a good interface. After some small redesigns along the way, I've ended up with a design that I am happy with. The main public interface only consists of two functions in a namespace (ignoring extra utility functions etc.).

Later I found that I needed to create some objects based on a bitflag parameter given in one of the functions. Both functions can be expected to be called very often (e.g. to process each frame of a video) where the flags are unlikely to change. So to avoid repeated object creation I made a utility function for reusing those objects based on the bitflag parameter (a simplistic object cache function with a static container of shared_ptr objects inside it if you're wondering). A cache class of some kind would probably be better, but I digress.

I now face the following design decision: Should I keep my functions or should I redesign my library around a main class instead?

I really like the simplicity of my two functions and creating an entire class feels like overengineering, and functions make more sense for the interface I feel. The main class would also have to coordinate processing calls (e.g. to process image frames), with subsequent getters to retrieve information.

On the other hand, a class will make reuse of objects more intuitive, do away with a bunch of function friend declarations, and better represent dependencies between multiple calls, whereas the functions would have a common dependency on object reuse which feels less intuitive since they are separate functions, but can perhaps work if designed correctly behind the scenes.

Answer 1

Neither.

Instead, consider making your code reentrant again:

1. Put all the costly but reusable state in a class.
2. Take that as an argument by reference, and clean up the interface to get rid of whatever you thus duplicated.
   (Whether you add a member forwarding to the free function is yours to decide.)
3. Add a convenience-function encapsulating both steps with the same interface and name as the old function had to preserve API and ABI compatibility, maybe with a [[deprecated]]-mark if you consider removing it in the future.