Delegating Behaviors in C++: A Practical Tour of the Available Mechanisms

Delegating behaviors to other parts of the code is essential for writing reusable, extensible, and flexible software.
C++ provides several mechanisms to achieve this: from virtual functions to function objects, from function pointers to lambdas, as well as templates, concepts, and more.
Each comes with its own strengths, trade-offs, and sweet spots.
In this talk, we will systematically explore the main options the language offers for passing behaviors — comparing their syntax, performance, flexibility, and suitability for different contexts.
The goal is to provide a reasoned roadmap that helps developers consciously choose the most appropriate mechanism based on their specific needs.

1. Delegating Behaviors in
C++: A Practical Tour of
the Available Mechanisms
Daniele Pallastrelli, daniele77.github.io
25.10.2025, Italian C++

2. So… whatisthe trulyuniquecharacteristicof C++?

3. C++ is
multiparadigm.
That’s what makes it truly powerful —and sometimes dangerous.

4. No building is
made from
one material –
neither should
your software
Use the right material for the right part.

5. Passing Behavior – The C++ way

6. Why passing behavior matters
Reusability — Extensibility — Testability
Non-functional properties that define quality.

7. Reusability
A component can be reused as-is across code and projects

8. Reusability
voidsort_users(std::vector<User>& users, ??? cmp)
{
// uses cmpas criterion to sort users
}

9. Reusability
classbutton: publicwidget
{
public:
voidon_click(??? handler)
{
// set the handler for the onclick event
}
};

10. Reusability
classuser
{
// ...
};
classcredential
{
// ...
};
classrole
{
// ...
};
Inject an authentication
mechanism (behavior)

11. Reusability
1 2

12. Extensibility
An application is extendible if it allows developers to add new features
or modify existing behaviors without altering the application's core
codeor requiring significant changes to its existing structure.

13. Extensibility

14. Testability
A software component is testable if its behavior can be reliably verified
without the component's core source code having to be modified or
'opened up' for internal inspection.
Unit test => Reusability
Reuse the component in a test environment.
Integration test => Extensibility
Test the whole systemand extend it with test doubles or stubs at its
boundaries.

15. What Can We Pass as a Behavior?
voidsort_users(std::vector<User>& users, ??? cmp)
{
// uses cmpas criterion to sort users
}

16. What Can We Pass as a Behavior? A Function
boolcompare_by_age(constUser& a, constUser& b)
{
returna.age< b.age;
}
...
sort_users(users, compare_by_age);
...

17. What Can We Pass as a Behavior? A Lambda
sort_users(users, [](constUser& a, constUser& b) { returna.age< b.age; });

18. What Can We Pass as a Behavior? A Functor
// Functor sorting users by age
structSortByAge{
booloperator()(constUser& a, constUser& b) const{
returna.age< b.age;
}
};
...
sort_users(users, SortByAge{});
...

19. What Can We Pass as a Behavior? A Polymorphic Object
// Interface for user comparison
classUserPredicate{
public:
virtual~UserPredicate() = default;
virtualboolcompare(constUser& a, constUser& b) const= 0;
};
// Concrete implementation of UserPredicateto sort by age
classSortByAge: publicUserPredicate{
public:
boolcompare(constUser& a, constUser& b) constoverride
{
returna.age< b.age;
}
};
...
sort_users(users, SortByAge{});
...

20. What about formal parameter types?
voidsort_users(std::vector<User>& users, ??? cmp)
{
// uses cmpas criterion to sort users
}

21. The Good Ol’ Function Pointer
usingCompFun= bool(constUser&, constUser&);
voidsort_users(std::vector<User>& users, CompFuncmp)
{
// uses cmpas criterion to sort users
}
You can pass:
•a free function
•a stateless lambda (implicitly convertible)
Note:
Member function pointers aren’t useful here: they bind the behavior to a specific instance.

22. Polymorphic Interface
•Enables runtime polymorphism
•Supports stateful behaviors
•Requires lifetime management (not necessarily heap allocation)
// Interface for user comparison
classUserPredicate{
public:
virtual~UserPredicate() = default;
virtualboolcompare(constUser& a, constUser& b) const= 0;
};
voidsort_users(std::vector<User>& users, constUserPredicate& cmp)
{
// uses cmp.compareas criterion to sort users
}

23. Templates (and Concepts)
•Supports any callabletype —something that provides operator () (functor,
lambda, free function, etc.)
•Zero-cost abstraction (Enables inlining and optimization)
•Behavior fixed at compile time(no runtime substitution)
•Hard to store or reuse later—type depends on the callable
•Must be defined in header file
•May increase code size
template<std::strict_weak_order<constUser&, constUser&> Compare>
voidsort_users(std::vector<User>& users, Compare cmp)
{
// uses cmpas criterion to sort users
}

24. std::function
•Holds any callable (lambda, functor, function pointer)
•Uniform, copyable, storable type
•Can be changed or reassigned at runtime
•Slight overhead, no inlining
voidsort_users(
std::vector<User>& users,
conststd::function<bool(constUser&, constUser&)>& cmp)
{
// uses cmpas criterion to sort users
}

25. std::variant + std::visit
•std::visit performs a type-safe runtime dispatch
•Behavior can’t be extended at runtime (closed set)
•Usually implemented with a jump table
structByAge{ boolcompare(constUser& a, constUser& b) { returna.age< b.age; } };
structByName{ boolcompare(constUser& a, constUser& b) { returna.name < b.name; } };
structById { boolcompare(constUser& a, constUser& b) { returna.id < b.id; } };
usingComparison= std::variant<ByAge, ByName, ById>;
voidsort_users(std::vector<User>& users, Comparisoncmp)
{
std::visit(
[&](auto&& comp) {
// use comp.compare(a,b) to sort users
},
cmp
);
}

26. Free function Lambda Functor
Polymorphic
Object
std::variant
Function pointer✓ Only stateless
Template ✓ ✓ ✓ ✓ ✓
std::function ✓ ✓ ✓ ✓ ✓
Interface ptr/ref ✓
std::variant ✓

28. Free function Lambda Functor
Polymorphic
Object
std::variant
Function pointer✓ Only stateless
Template ✓ ✓ ✓ ✓ ✓
std::function ✓ ✓ ✓ ✓ ✓
Interface ptr/ref ✓
std::variant ✓

33. Where is this case?
template<typenameF>
voidfoo(Fcallback)
{
// do something useful and provide result
callback(result);
}

34. Where is this case?
… it depends:
template<typenameF>
voidfoo(Fcallback)
{
// do something useful and provide result
callback(result);
}
voidbar(intr)
{
cout<< r;
}
foo(bar);
structBar{
voidoperator()(intr) const
{ cout<< r; }
};
foo(Bar{});
foo([](intr) { cout << r; });

35. voidbar(intr)
{
cout<< r;
}
foo(bar);
structBar{
voidoperator()(intr) const
{ cout<< r; }
};
foo(Bar{});
foo([](intr) { cout << r; });
template<>
voidfoo<Bar>(Barcb)
{
// calculateresult
cb.operator()(result);
}
template<>
voidfoo<void(*)(int)>(void(*cb)(int))
{
// calculateresult
cb(result);
}
template<>
voidfoo<__lambda_28_7>(__lambda_28_7 cb)
{
// calculateresult
cb.operator()(result);
}

36. voidbar(intr)
{
cout<< r;
}
foo(bar);
structBar{
voidoperator()(intr) const
{ cout<< r; }
};
foo(Bar{});
foo([](intr) { cout << r; });
template<>
voidfoo<Bar>(Barcb)
{
// calculateresult
cb.operator()(result);
}
template<>
voidfoo<void(*)(int)>(void(*cb)(int))
{
// calculateresult
cb(result);
}
template<>
voidfoo<__lambda_28_7>(__lambda_28_7 cb)
{
// calculateresult
cb.operator()(result);
}

37. voidbar(intr)
{
cout<< r;
}
foo(bar);
structBar{
voidoperator()(intr) const
{ cout<< r; }
};
foo(Bar{});
foo([](intr) { cout << r; });

38. When a lambda beats a function pointer…
template<typenameF>
voidexec(F&& f) {
std::forward<F>(f)();
}
autofoo= []() {};
exec(foo);
voidbar() {}
exec(bar);

39. -Call to std::function::operator()
-Type-erasure dispatch through a virtual function
-Template instantiation for the original callable type
-The invoker calls the actual callable

40. std::visit jump table
std::visit(visitor, var);
staticconstexprautotable[] = {
[](auto& vis, auto& var) -> decltype(auto) { vis(std::get<A>(var)); },
[](auto& vis, auto& var) -> decltype(auto) { vis(std::get<B>(var)); },
[](auto& vis, auto& var) -> decltype(auto) { vis(std::get<C>(var)); }
};
table[var.index()](visitor, var);

41. structCircle { voiddraw() { /* ... */} };
structSquare { voiddraw() { /* ... */} };
structTriangle{ voiddraw() { /* ... */} };
std::variant<Circle, Square, Triangle> obj;
std::visit(
[&](auto&& shape) { shape.draw(); }, // visitor
obj// variant
);
staticconstexprautotable[] = {
[](auto& vis, auto& var) -> decltype(auto) { vis(std::get<Circle>(var)); },
[](auto& vis, auto& var) -> decltype(auto) { vis(std::get<Square>(var)); },
[](auto& vis, auto& var) -> decltype(auto) { vis(std::get<Triangle>(var)); }
};
autovisitor = [&](auto&& shape) { shape.draw(); };
table[obj.index()](visitor, obj);

42. -Check the index stored in the std::variant
-Jump to the right case in the jump table
-Setup the operands
-Call the function (can be inlined)

43. Micro-benchmarks: what they really tell us?
Influenced by:
•Library optimizations (std::function, std::visit, …)
•Compiler optimizations (inlining, devirtualization, …)
•Hardware effects (cache, branch prediction, …)
The second should not be part of the benchmark
Micro-benchmarks measure the benchmark itself, not your application!
Real optimization = profile the real system
Performance can vary with compilers, versions, flags, CPUs, load, execution path
What is stable are the design propertiesof C++ constructs

44. Speed fades.
Design stays.

45. Keeping a partial state of computation
Free function
•Global or static data, singleton & c (booh!)
•C idiom: function ptr + void* parameter
Lambda
•Captures local variables (by copy / ref)
•Init-capture and mutable
Functor
•Keeps state in member variables
Polymorphic object
•Derived class stores its own state
std::variant
•Each alternative carries its own state

46. Scattering vs. Gathering (AKA Functions vs. Objects)
Functions/lambdas:
single behavior (how to do one thing)
Objects, functors, polymorphic objects, or std::variant:
multiple related behaviors (how this kind of things behaves)
Objects can share stateand group coherent logic.
Guideline:
If behaviors belong together, keep them together—wrap them into a single
object instead of scattering separate functions.

47. Passing Logic vs. Passing Behavior
With functionsor lambdas, you pass a piece of logic to execute.
With polymorphic objects, functors, or std::variant, you pass a value
that embodiesthe behavior.

48. Case 1 (easy): throw-away policy
Use policy immediately
Easy, just a method template
classUserRepository{
public:
template<typenamePolicy>
voidprocess_users(Policy policy)
{
// use policy here, e.g., apply policy to process users
}
};

49. Case 2 (hard): long-lived policy
Store policy for later use
classUserRepository{
public:
template<typenamePolicy>
voidset_policy(Policyp)
{
// store the policy to later use, uhm...
policy = p;
}
voiduse_policy()
{
// use the storedpolicy
}
private:
??? policy;
};

50. Solution #1: class template
template<typenamePolicy>
classUserRepository{
public:
explicitUserRepository(Policyp) : policy(std::move(p)) {}
voiduse_policy()
{
// use the storedpolicy
}
private:
Policypolicy;
};
intmain()
{
UserRepositoryusers{
[](){ /* do something useful */ }
}; // C++17 type deduction from constructor arguments
users.use_policy();
}

51. Solution #1: class template
template<typenamePolicy>
classUserRepository{
public:
explicitUserRepository(Policyp) : policy(std::move(p)) {}
voiduse_policy()
{
// use the storedpolicy
}
private:
Policypolicy;
};
intmain()
{
UserRepositoryusers{
[](){ /* do something useful */ }
}; // C++17 type deduction from constructor arguments
users.use_policy();
}

52. // Main class parametrized by policies
template<typenameLoggerPolicy, typenameStoragePolicy>
classMyService: privateLoggerPolicy, privateStoragePolicy{
public:
voidsave(conststd::string& data) {
this->log("Saving data: "+ data); // logging policy
this->store(data); // storage policy
}
};
Solution #2: Alexandrescu policy-based design

53. // Main class parametrized by policies
template<typenameLoggerPolicy, typenameStoragePolicy>
classMyService: privateLoggerPolicy, privateStoragePolicy{
public:
voidsave(conststd::string& data) {
this->log("Saving data: "+ data); // logging policy
this->store(data); // storage policy
}
};
Solution #2: Alexandrescu policy-based design
Not really about passing behavior
But composing behaviors at compile time

54. Solution #3: type erasure
classUserRepository{
public:
template<typenamePolicy>
voidset_policy(Policy&& p)
{
policy = std::forward<Policy>(p);
}
voiduse_policy() { if(policy) policy(); }
private:
std::function<void(void)> policy;
};
intmain()
{
UserRepositoryusers;
users.set_policy( []() { /* do something useful */ } );
users.use_policy();
}

55. Solution #3: type erasure
classUserRepository{
public:
template<typenamePolicy>
voidset_policy(Policy&& p)
{
policy = std::forward<Policy>(p);
}
voiduse_policy() { if(policy) policy(); }
private:
std::function<void(void)> policy;
};
intmain()
{
UserRepositoryusers;
users.set_policy( []() { /* do something useful */ } );
users.use_policy();
}

56. Solution #3: type erasure (the oldest one ☺ )
structPolicy{
virtual~Policy() = default;
virtualvoidapply() = 0;
};
structPrintPolicy: Policy{
voidapply() override
{
// do something useful
}
};
classUserRepository{
public:
voidset_policy(std::unique_ptr<Policy> p)
{
policy = std::move(p);
}
voiduse_policy() { if(policy) policy->apply(); }
private:
std::unique_ptr<Policy> policy;
};
intmain()
{
UserRepositoryusers;
users.set_policy(std::make_unique<PrintPolicy>());
users.use_policy();
}
GoF Strategy Pattern

57. Solution #3: type erasure (the oldest one ☺ )
structPolicy{
virtual~Policy() = default;
virtualvoidapply() = 0;
};
structPrintPolicy: Policy{
voidapply() override
{
// do something useful
}
};
classUserRepository{
public:
voidset_policy(std::unique_ptr<Policy> p)
{
policy = std::move(p);
}
voiduse_policy() { if(policy) policy->apply(); }
private:
std::unique_ptr<Policy> policy;
};
intmain()
{
UserRepositoryusers;
users.set_policy(std::make_unique<PrintPolicy>());
users.use_policy();
}

58. Storing the behavior
It depends on howyour interface accepts the behavior
•Function pointer
•Interface reference or pointer
•std::function
•std::variant
All can store behaviors directly
•Template
You need some form of type erasure to store it or make the whole
class a template (deciding everything at compile-time)

59. Run-time substitution vs. compile-time definition
When is Run-Time Change Essential?
•Configuration is user-dependent (e.g., choosing from a config file which
algorithm to use).
•Flexibility is required (run-time loaded plugins, drivers, rule engines).
•You must react to variable conditions (e.g., if the network is slow -> change
the caching policy; if the train enters a tunnel -> change the communication
strategy).
•You want to test/swap behaviors without rebuilding (e.g., in embedded or
mission-critical systems where recompiling isn’t always feasible).
With a template interface you cannot change the behavior at run-time

60. Runtime Extensibility
Template class and std::variant:
•Closed Set of Types at Compile-Time
•Can’t use in plugin-based or dynamic architectures.

61. Template propagation

62. Template propagation
classFoo{
std::function<void(void)> policy;
};
classFooClient{
Foofoo; // no dependency from policy
};
template<typenamePolicy>
classBar{ /* ... */};
// template class
template<typenamePolicy>
classBarClient1{
Bar<Policy> bar;
};
// depends on ConcretePolicy
classBarClient2{
Bar<ConcretePolicy> bar;
};
Class using std::function or interface
The dependency is hidden inside the
class
Users don’t need to know what
behavior it contains – they only depend
on its interface
Only the creator of Foo—the one who
injects the behavior —needs to know
which behavior is used.

63. Template propagation
classFoo{
std::function<void(void)> policy;
};
classFooClient{
Foofoo; // no dependency from policy
};
template<typenamePolicy>
classBar{ /* ... */};
// template class
template<typenamePolicy>
classBarClient1{
Bar<Policy> bar;
};
// depends on ConcretePolicy
classBarClient2{
Bar<ConcretePolicy> bar;
};
Template class Bar<T>
The dependency is exposed in the type.
Anyone using Bar must either:
•Explicitly know which T is used
(impractical —policies leak all over the
code), or
•Be a template themselves (cascade
effect: parameters multiply —
everything becomes a header)

64. Template propagation
classFoo{
std::function<void(void)> policy;
};
classFooClient{
Foofoo; // no dependency from policy
};
template<typenamePolicy>
classBar{ /* ... */};
// template class
template<typenamePolicy>
classBarClient1{
Bar<Policy> bar;
};
// depends on ConcretePolicy
classBarClient2{
Bar<ConcretePolicy> bar;
};
Templates propagate dependencies at compile-time
Interfaces and std::function contain them

65. Summary
Use template if:
•Performances needed AND
•Confined in a subsystem
Else
•Use polimorphism or std::function
A hybrid is common:
•Use templates internally for performance-critical parts.
•Use type-erasure at architectural boundaries to avoid propagating templates
everywhere.

66. What we’ve explored
•Why passing behaviors matters
•The main techniques C++ gives us
•How they work under the hood
•Performance insights
•And a glimpse into design consequences

67. What to take away
Before writing code, think about the alternatives.
Don’t pick a technique just because it’s faster—
performance depends on context, and you’ll never really know until you measure your
owncode.

68. Remember
C++ is multi-paradigm.
Use all the tools it gives you.
Don’t build your entire house out of glass —
not even the foundations.

70. References
Me: [email protected]
Me: @DPallastrelli
Github: http://github.com/daniele77
Web: softwareexploring.blogspot.com
70