3 ms·
You are trying to apply concepts where the paradigm your are operating in (C or C++'s) doesn't solve the problem the same way. In C++, you forward responsibili
by munchbunny 8y ago
You are trying to apply concepts where the paradigm your are operating in (C or C++'s) doesn't solve the problem the same way.
In C++, you forward responsibility for knowing object shape down the line of composition. You also generally avoid deep copies because they are expensive. This leads to using getter/setter methods to abstract object shape at module boundaries. If you're dealing with immutable objects, then you bake that into the interface (such as std::string).
If you were deep copying objects in C++, first I would ask whether you really need to. If you really did, then the idiomatic way is to either provide a function like ".clone" or to implement the copy constructor to do it.
How do you pass a member identification as a parameter to a function that may receive any kind of structure, and then update that member?
You don't, because that's not something C++ as a language can do. So instead, the question is how you got into a situation in C++ where you need to.
On the point about composability, in C++ the composition happens at the object level. You don't compose getting/setting functions because that's not how C++ addresses the same problem.