auto-generate method calls to every member object of a class - c++

Question

I would like to be able to 'forward' a member function call of a class to every member variable of the class:
class MyObject {
X_Behavior v1;
X_Behavior v2;
...
Y_Behavior v10;
Z_Behavior v11;
...
public:
void clear() { v1.clear(); v2.clear(); ... v10.clear(); v11.clear(); }
void hide() { v1.hide(); v2.hide(); ... v10.hide(); v11.hide(); }
void show() { v1.show(); v2.show(); ... v10.show(); v11.show(); }
};
All these functions are implemented in every component class,
according to the expected 'behavior'.
e.g.
class X_Behavior {
public:
void clear();
void hide();
void show();
...
};
Manual copying if these iterations
void clear() { v1.clear(); v2.clear(); ... v10.clear(); v11.clear(); }
void hide() { v1.hide(); v2.hide(); ... v10.hide(); v11.hide(); }
void show() { v1.show(); v2.show(); ... v10.show(); v11.show(); }
... more similar members here ...
is hard to maintain and review.
There are many classes like MyObject, each with many member variables.
Many developers edit them.
Also, you cannot tell whether an ommitted call or a mixed order was intentional or not.
Can you propose a compiler-generated construct that allows me to implement these functions once and not touch them again?
void MyObject::clear() { /* call clear() for every (_Behavior) member of this class */ }
void MyObject::hide() { /* call hide() for every (_Behavior) member of this class */ }
void MyObject::show() { /* call show() for every (_Behavior) member of this class */ }
I do not wish to increase the size of MyObject.
The *_Behavior classes should stay as they are.
Not to be tied to a base class.
I want to do this without employing the Preprocessor.
Can you propose a C++11/17/20 solution for this?
Ideally, I would like to see if this could be done with minimal code, just like
the compiler generated default implementations for constructor, copy constructor, assignments, destructor.

Answer 1

1. std::tuple + std::apply
A simple C++17 solution to your problem would be to add an additional method that returns references to all behaviors, then you can use std::apply with a templated lambda to reduce it to the individual calls.
e.g.: godbolt example
class MyObject {
BehaviorA v1;
BehaviorA v2;
BehaviorB v3;
BehaviorB v4;
constexpr auto behaviors() { return std::tie(v1, v2, v3, v4); }
public:
void clear() {
std::apply(
[](auto&&... behavior) { (behavior.clear(), ...); },
behaviors()
);
}
};
Pros:
Easily optimizeable by compilers, will mostly result in the same code as the manual function calls
Cons:
You have to remember to add each new behavior to behaviors().
2. boost::pfr::for_each_field
If you don't mind using boost you can enhance this by putting all the behaviors into an aggregate struct (since C++14 (but C++17 makes it a lot easier) you can sort-of reflect the members of aggregates by using aggregate initialization - this is often called "magic tuple")
e.g.: godbolt example
struct BehaviorA { void clear() { std::cout << "CLEAR A" << std::endl; } };
struct BehaviorB { void clear() { std::cout << "CLEAR B" << std::endl; } };
class MyObject {
struct MyObjectBehaviours {
BehaviorA v1;
BehaviorA v2;
BehaviorB v3;
BehaviorB v4;
} behaviors;
public:
void clear() {
boost::pfr::for_each_field(behaviors, [](auto&& behavior) {
behavior.clear();
});
}
};
Pros:
Very hard to mess up with this one
Can be optimized very good
Cons:
Needs boost
2.1 magic tuples without boost
You can also do the same without using boost, you'll have to write quite a bit of code though:
godbolt example
template<class T>
concept aggregate = std::is_aggregate_v<T>;
struct any_type {
template<class T>
operator T() {}
};
template<aggregate T>
consteval std::size_t count_members(auto ...members) {
if constexpr (requires { T{ members... }; } == false)
return sizeof...(members) - 1;
else
return count_members<T>(members..., any_type{});
}
template<aggregate T>
constexpr auto tie_struct(T& data) {
constexpr std::size_t fieldCount = count_members<T>();
if constexpr(fieldCount == 0) {
return std::tie();
} else if constexpr (fieldCount == 1) {
auto& [m1] = data;
return std::tie(m1);
} else if constexpr (fieldCount == 2) {
auto& [m1, m2] = data;
return std::tie(m1, m2);
} else if constexpr (fieldCount == 3) {
auto& [m1, m2, m3] = data;
return std::tie(m1, m2, m3);
} else if constexpr (fieldCount == 4) {
auto& [m1, m2, m3, m4] = data;
return std::tie(m1, m2, m3, m4);
} else {
static_assert(fieldCount!=fieldCount, "Too many fields for tie_struct! add more if statements!");
}
}
template<aggregate T, class Callable>
constexpr void for_each_field(T& data, Callable&& callable) {
std::apply([&callable](auto&&... members){
(callable(members), ...);
}, tie_struct(data));
}
struct BehaviorA { void clear() { std::cout << "CLEAR A" << std::endl; } };
struct BehaviorB { void clear() { std::cout << "CLEAR B" << std::endl; } };
class MyObject {
struct MyObjectBehaviours {
BehaviorA v1;
BehaviorA v2;
BehaviorB v3;
BehaviorB v4;
} behaviors;
public:
void clear() {
for_each_field(behaviors, [](auto&& behavior) {
behavior.clear();
});
}
};
Pros:
Same as above
Cons:
Needs a lot of boilerplate code (but that can also be used for other things - structure reflection is always useful :D )
3. std::variant array
With std::variants you can combine all your behaviors into a single array (it's basically an union of all possible behaviors), then you can use a simple for-loop with std::visit to access the individual behaviors:
e.g.: godbolt example
struct BehaviorA { BehaviorA(int) {} void clear() { std::cout << "CLEAR A" << std::endl; } };
struct BehaviorB { BehaviorB(float) {} void clear() { std::cout << "CLEAR B" << std::endl; } };
class MyObject {
using Behavior = std::variant<BehaviorA, BehaviorB>;
Behavior behaviors[4];
public:
MyObject() : behaviors {
Behavior{std::in_place_type<BehaviorA>, 1},
Behavior{std::in_place_type<BehaviorA>, 2},
Behavior{std::in_place_type<BehaviorB>, 1.0f},
Behavior{std::in_place_type<BehaviorB>, 2.0f}
} {
}
void clear() {
for(auto& b : behaviors)
std::visit([](auto& behavior) {
behavior.clear();
}, b);
}
};
Pros:
Easy to use, no allocations
Cons:
If you want to access only a single element it gets hairy, e.g.:
auto& b = std::get<BehaviorA>(behaviors[0]);
No names for the individual behaviors, only array indices
Potentially wastes a lot of memory (if some behaviors are a lot larger than others)

Answer 2

I think that your best option is to create a base class for the Behavior classes. If you really want to avoid that, you could store them as unions (or std::variants, but it would make the code needlessly more complicated and less readable.