This article deals with getters and setters in C++. I am sorry, it is not about coroutine, but part 2 of thread pools will come in the following weeks.
TL;DR: Getters and setters are bad for structure like objects.
Introduction
In this article, I will only give my opinion about them, I don’t want to offend anyone, I am just going to explain why, or why not, use getters and setters. I would be glad to have any debates in the comments part.
Just to be clear about what I am talking about when I talk about getter, I talk about a function that just returns something, and when I talk about setter, I talk about a function that just modifies one internal value, not doing any verification or other computations.
Getter performances
Let’s say we have a simple structure with their usual getter and setters:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
class PersonGettersSetters { public: std::string getLastName() const { return m_lastName; } std::string getFirstName() const { return m_firstName; } int getAge() const {return m_age; } void setLastName(std::string lastName) { m_lastName = std::move(lastName); } void setFirstName(std::string firstName) { m_firstName = std::move(firstName); } void setAge(int age) {m_age = age; } private: int m_age = 26; std::string m_firstName = "Antoine"; std::string m_lastName = "MORRIER"; }; |
Let’s compare this version with the one without getters and setters.
|
1 2 3 4 5 |
struct Person { int age = 26; std::string firstName = "Antoine"; std::string lastName = "MORRIER"; }; |
It is incredibly shorter and less error_prone. We can not make the error to return the last name instead of the first name.
Both codes are fully functional. We have a class Person with the first name, the last name, and an age. However, let’s say we want a function that returns the presentation of a person.
|
1 2 3 4 5 6 7 8 |
std::string getPresentation(const PersonGettersSetters &person) { return "Hello, my name is " + person.getFirstName() + " " + person.getLastName() + " and I am " + std::to_string(person.getAge()); } std::string getPresentation(const Person &person) { return "Hello, my name is " + person.firstName + " " + person.lastName + " and I am " + std::to_string(person.age); } |
The version without getters performs this task 30% quicker than the version with getters. But why? It is because of the return by value of the getters functions. Returning by value makes a copy that results in poorer performance. Let’s compare the performance between person.getFirstName(); and person.firstName.
As you can see, accessing directly the first name instead of a getter is equivalent to a noop.
Getter by const reference
However, it is possible to not return by value but return by reference instead. Going that way, we will have the same performance as without getters. The new code will look like that
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
class PersonGettersSetters { public: const std::string &getLastName() const { return m_lastName; } const std::string &getFirstName() const { return m_firstName; } int getAge() const {return m_age; } void setLastName(std::string lastName) { m_lastName = std::move(lastName); } void setFirstName(std::string firstName) { m_firstName = std::move(firstName); } void setAge(int age) {m_age = age; } private: int m_age = 26; std::string m_firstName = "Antoine"; std::string m_lastName = "MORRIER"; }; |
Since we get the same performance as before, are we done? To answer this question, you can try to execute this code.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
PersonGettersSetters make() { return {}; } int main() { auto &x = make().getLastName(); std::cout << x << std::endl; for(auto x : make().getLastName()) { std::cout << x << ","; } } |
You may see some weird characters wrote in the console. But why? What happened when you do make().getLastName()?
- You create a
Person - You get a reference to the last name
- You delete Person
You have a dangling reference! It can lead to a crash (in the best case) or something worst than what can be found in a horror movie.
To deal with such a thing, we must introduce reference qualified functions.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
class PersonGettersSetters { public: const std::string &getLastName() const & { return m_lastName; } const std::string &getFirstName() const & { return m_firstName; } std::string getLastName() && { return std::move(m_lastName); } std::string getFirstName() && { return std::move(m_firstName); } int getAge() const {return m_age; } void setLastName(std::string lastName) { m_lastName = std::move(lastName); } void setFirstName(std::string firstName) { m_firstName = std::move(firstName); } void setAge(int age) {m_age = age; } private: int m_age = 26; std::string m_firstName = "Antoine"; std::string m_lastName = "MORRIER"; }; |
Here is the new solution that works everywhere. You need 2 getters. One for lvalue and one for rvalue (both xvalue and prvalue).
Setter issues
There is not a lot to say in this section. If you want to achieve the best performances, you must write a setter that takes a lvalue and one that takes a rvalue. However, it is generally fine to just have a setter that takes a value that will be moved. Nevertheless, you have to pay the price of an extra move. However, that way, you cannot just make a little enhancement. You must replace the whole variable. If you just wanted to replace one A by a D in a name, it will not be possible by using setters. However, using direct access makes it possible.
What about immutable variables?
Ones will tell you to just make the member attribute as const. However, I am not ok with this solution. Indeed, making it const will prevent the move semantic and will lead to unnecessary copy.
I have no magic solution to propose you right now. Nevertheless, we can write a wrapper which we can named immutable<T>. This wrapper must be able to be :
- Constructible
- Since it is immutable, it must not be assignable
- It can be copy constructible or move constructible
- It must be convertible to
const T&when being a lvalue - It must be convertible to
Twhen being a rvalue - It must be used like other wrapper through
operator*oroperator->. - It must be easy to get the address of the underlying object.
Here is a little implementation
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
#define FWD(x) ::std::forward<decltype(x)>(x) template <typename T> struct AsPointer { using underlying_type = T; AsPointer(T &&v) noexcept : v{std::move(v)} {} T &operator*() noexcept { return v; } T *operator->() noexcept { return std::addressof(v); } T v; }; template <typename T> struct AsPointer<T &> { using underlying_type = T &; AsPointer(T &v) noexcept : v{std::addressof(v)} {} T &operator*() noexcept { return *v; } T *operator->() noexcept { return v; } T *v; }; template<typename T> class immutable_t { public: template <typename _T> immutable_t(_T &&t) noexcept : m_object{FWD(t)} {} template <typename _T> immutable_t &operator=(_T &&) = delete; operator const T &() const &noexcept { return m_object; } const T &operator*() const &noexcept { return m_object; } AsPointer<const T &> operator->() const &noexcept { return m_object; } operator T() &&noexcept { return std::move(m_object); } T operator*() &&noexcept { return std::move(m_object); } AsPointer<T> operator->() &&noexcept { return std::move(m_object); } T *operator&() &&noexcept = delete; const T *operator&() const &noexcept { return std::addressof(m_object); } friend auto operator==(const immutable_t &a, const immutable_t &b) noexcept { return *a == *b; } friend auto operator<(const immutable_t &a, const immutable_t &b) noexcept { return *a < *b; } private: T m_object; }; |
So, for an immutable Person, you can just write:
|
1 2 3 4 5 |
struct ImmutablePerson { immutable_t<int> age = 26; immutable_t<std::string> firstName = "Antoine"; immutable_t<std::string> lastName = "MORRIER"; }; |
Conclusion
I would not say that getters and setters are bad. However, when you do not need to do anything else in your getter and your setter, achieving the best performance, safety and flexibility lead to writing:
- 3 getters (or even 4): const lvalue, rvalue, const rvalue, and if you want, non-const lvalue (even if sounds really weird since it is easier to just use direct access)
- 1 setter (or 2 if you want to have the maximum performance)
It is a lot of boilerplate for almost anything.
Some people will tell you that getters and setters enforce encapsulation, but they don’t. Encapsulation is not just making attributes private. It is about hiding things from users, and for structure-like objects, you rarely want to hide anything.
My advice is: when you have a structure like objects, just don’t use getter and setters and go with public / direct access. To be simple, if your setter does not enforce any invariant, you don’t need a private attribute.
PS: For people who use libraries using shallow copy, the performance impact is less important. However, you still need to write 2 functions instead of 0. Don’t forget, the less code you write, the less bugged it will be, easier to maintain, and easier to read.
And you ? Do you use getters and setters? And why?