hell_ical_vortex hell_ical_vortex - 3 months ago 18
C++ Question

Reference return for setter

A. How useful/cumbersome is the following trick of using the same function for getter as well as setter, by returning a reference?

B. How good is the practice of adding const to the end of function declarations in case of getters and setters?

#include <iostream>

class A
{
int varReadWrite_;
int varReadOnly_;
int varRestricted_;

public:
A() : varReadOnly_(25) {}
virtual ~A() {}

int& varReadWrite() { return varReadWrite_; }
int varReadOnly() { return varReadOnly_; }
int varRestricted() { return varRestricted_; }
void setVarRestricted(int i); //throwable

};

int main(int argc, char *argv[])
{
A a;
a.varReadWrite() = 45;
std::cout << a.varReadOnly() << a.varReadWrite() << std::endl;
return 0;
}


The reasons, why I chose this design was:


  1. ease of access of explicitly read-only or explicitly writable variables.

  2. the restricted (I dont know what else to call them), the variables, that require sanitization and filtering before being assigned -- these variables might require an explicit setter.



Using boost fusion map is also an interesting possibility as shown here

Update

Const Reference Members are interesting for read-only access to variables, e.g.

class A {
int mA;
public:
int& a;
A(int a_ = 0) : mA(a_), a(mA) {}
};


Practically this comes with the extra effort to code the copy and move constructors, which is an acceptable compromise for me.

Cpp Reference Copy Construtor says


The implicitly-declared or defaulted copy constructor for class T is defined as deleted if... T has non-static data members that cannot be copied (have deleted, inaccessible, or ambiguous copy constructors);

Answer

A. How useful/cumbersome is the following trick of using the same function for getter as well as setter, by returning a reference?

Returning a reference to your internal members in general is not recommended since this way you give an easy access to others so they could change your object internal state without using any method provided by the object's class API. Thus, it will be very difficult to track this kind of changes in the code. In general changes in the internal state of an object should only be possible through methods that belongs to the class API.

B. How good is the practice of adding const to the end of function declarations in case of getters and setters?

if you refer to adding const for methods like:

void PrintState() const

Then in general this doesn't make sense for setters. Const in this case means This method doesn't change the object state. So it's a commitment that you give to the caller to say: I will not change the object state by this call. In general it's very good practice since it helps you during the design to think about your methods and see which one is really modifying the object state or not. Additionally, it's a defensive programming since it's recursive: if you pass this object to some method by reference (through a pointer or reference) he can't call const methods unless this method is marked as const also. So this prevents from changing the object state by error.

Comments