Overload of single method vs get/set for properties in C++?

Question

I have a class A with a property named prop of type int. Getters and setters are usually implemented as follows:

class A
{
    void set_prop(int value);   // set
    int get_prop() const;    // get
}

Is there a reason to prefer this design, instead of using two overloads with the same name, as follows?

class A
{
    void prop(int value);   // set
    int prop() const;    // get
}

I like the last form better (maybe it's just a matter of taste). But I have usually seen the first form. So I am wondering if there is a deep reason to prefer one over the other? That is, is this just a matter of style, or is there an Object Oriented principle that says one is better than the other?

It's best to avoid this silly pattern altogether... and where's your `const`? — Lightness Races in Orbit, Jul 29 '15 at 21:02
The first is more readable and more widely used in C++. The second is a more .NET, property-driven language type deal that is almost the same as making the value public. It is better to avoid it all together aforementioned. — TheSmartWon, Jul 29 '15 at 21:03
@ZackAllen I would not say that the second is close to .NET, neither that it is close ti exposing backers. — AlexD, Jul 29 '15 at 21:06
Relevant: http://stackoverflow.com/questions/737409/are-get-and-set-functions-popular-with-c-programmers?rq=1 — TheSmartWon, Jul 29 '15 at 21:07
@LightnessRacesinOrbit Why is `const` needed? The getters work just fine without, don't they? — Jashaszun, Jul 29 '15 at 21:08
@Jashaszun: Not if your object is `const`, no... Why would you _not_ make a getter `const`? — Lightness Races in Orbit, Jul 29 '15 at 21:08
@becko: The close vote is mine and it's because you are asking for opinions on coding style. That is off-topic here. — Lightness Races in Orbit, Jul 29 '15 at 21:08
@LightnessRacesinOrbit I'm not trying to be purposefully thick here, so sorry if it sounds dumb: the `int` that is getting returned isn't `const`, so why would you declare it as such (or declare the getter as a `const` function)? When *do* you want to make a getter `const`? — Jashaszun, Jul 29 '15 at 21:10
@LightnessRacesinOrbit You are partly right. I am not asking for opinion on coding style. Rather, I am asking if the difference between the two forms is *only* a matter of style. If it is, then I'll for the second one because I prefer it. But if there is a deeper reason than just style, I would like to know it. I edited to question to make that point clearer. — a06e, Jul 29 '15 at 21:11
@Jashaszun: Always..... A member function that does not mutate its class instance should be marked `const` so that it may be invoked on a `const` class instance (or otherwise through an expression of `const` class type). There is no point in prohibiting such a call (which you do by omitting `const`) if the function does not mutate its class instance. When do you use member-function `const` if not here?! And I have no idea what the return type has to do with it. — Lightness Races in Orbit, Jul 29 '15 at 21:12
@becko: Of course it is. It's just a name. Though Anthony has a reasonable point about overload resolution. — Lightness Races in Orbit, Jul 29 '15 at 21:14
@LightnessRacesinOrbit Oh... I guess I've never used this feature before. I just read http://stackoverflow.com/questions/3141087/what-is-meant-with-const-at-end-of-function-declaration and now it makes sense. I previously thought that "since functions are *already* const, the `const` must apply to the return type `int`, not the function itself, and what's the point of that?" — Jashaszun, Jul 29 '15 at 21:14
People keep voting to close without giving the reason. I tried to fix the question. Please, state the reason to close. — a06e, Jul 29 '15 at 21:20

score 1 · Answer 1 · answered Jul 29 '15 at 21:12

The rationale behind choosing the first style is one of semantics. A (member in this case) function represents an action and calling a function carries the meaning of requesting the associated action be executed. Because of this, they're typically named after verbs:

get_property()
create_foo()
compute_bar()
show_button()

It's also clearer what you're doing in some contexts, such as when taking the address of a member function:

auto foo = &A::property; 
// Is property a member function or a member variable here?

No one is stopping you from going with the second option, in fact a lot of people use a mix of both but the first one definitely aligns better with what a function or method represents in a programming language.

Lawrence Aiello · Answer 2 · 2015-07-29T21:06:09.397

0

The first form is much easier to understand from a maintenance perspective.

Remember, you're not just programming for you, but for every person who has to read/modify your code afterwards. So I would go with the first form since the function names easily say what they do.

edited Jul 29 '15 at 21:06

answered Jul 29 '15 at 21:02

Lawrence Aiello

4,560
5
21
35

2

What "standard"? The first form is actually _not_ what the C++ standard uses; the second form is. So, um.. – Lightness Races in Orbit Jul 29 '15 at 21:02
1

Changed it. I meant "standard" as in the first form is the way I have seen it, and am willing to bet most others have seen also. – Lawrence Aiello Jul 29 '15 at 21:06
The 'standard' is pretty trivial over something like this. I agree, it's best to go with something readable. – TheSmartWon Jul 29 '15 at 21:06
Where is this "standard" written? If it's just a matter of readability, then it is a matter of taste, I think. I find the second form more readable. That's my opinion, anyway. – a06e Jul 29 '15 at 21:07
@LawrenceAiello: There is no meaning of "standard" that would have been correct there. That was my main point. The fact that the C++ standard happens to disagree with your viewpoint was an ironic added bonus ;) – Lightness Races in Orbit Jul 29 '15 at 21:07
@becko I respectfully disagree. Some programmers "taste" is to name every variable with a single character like `x` and `y`. You may think it makes sense to you, but to the poor sod who has to read it after you leave the company, it makes no sense. – Lawrence Aiello Jul 29 '15 at 21:09
@LawrenceAiello: Unless those variables represent co-ordinates in a Cartesian system, such programmers should be shot! The same goes for whoever allowed the code to escape code review. – Lightness Races in Orbit Jul 29 '15 at 21:09

score 0 · Answer 3 · answered Jul 29 '15 at 21:16

You have two functions with the same name, but their responsibilities are discrete from each other. One of them has a side-effect of modifying the state of an object, the other one only reads and returns the state of an object. The underlying principle here, I believe, is simply separation of concern.

Overload of single method vs get/set for properties in C++?

3 Answers3