Are get and set functions popular with C++ programmers?

Question

I'm from the world of C# originally, and I'm learning C++. I've been wondering about get and set functions in C++. In C# usage of these are quite popular, and tools like Visual Studio promote usage by making them very easy and quick to implement. However, this doesn't seem to be the case in the C++ world.

Here's the C# 2.0 code:

public class Foo {     private string bar;      public string Bar     {         get { return bar; }         set { bar = value; }     } } 

Or, in C# 3.0:

public class Foo { get; set; } 

May people will say, well whats the point in that? Why not just create a public field and then make it a property later if you need to; honestly, I'm actually not sure. I just do it out of good practice because I've seen it done so many times.

Now because I'm so used to doing it, I feel like I should carry over the habit to my C++ code, but is this really necessary? I don't see it done as often as with C#.

Anyway, here's the C++ from what I gather:

class Foo { public:     std::string GetBar() const; // Thanks for the tip, @Daniel Earwicker.     void SetBar(std::string bar); private:     std::string bar; }  std::string Foo::GetBar() const {     return bar; }  void Foo::SetBar(std::string bar) {     // Also, I always wonder if using 'this->' is good practice.     this->bar = bar; } 

Now, to me that seems like a whole lot of leg work; considering using Visual Studio's tools the C# implementation would take literally seconds to implement, and the C++ took me a lot longer to type - I feel its not worth the effort, especially when the alternative is 5 lines long:

class Foo { public:     std::string Bar; } 

From what I gather, these are the advantages:

• You can change implementation details for the get and set functions, so instead of returning a private field you can return something more interesting.
• You can remove a get/set later on and make it read/write only (but for a public facing interface, this seems, not good).

And the disadvantages:

• Takes ages to type, is this really worth the effort? Generally speaking. In some cases, the advantages make it worth the effort, but I mean, speaking in terms of "good practice", is it?

Answer:

Why did I choose the answer with less votes? I was actually very close to choosing veefu's answer; however my personal opinion (which is apparently controversial), is that the answer over egged the pudding.

The answer I chose, on the other hand, seems to argue both sides; I think getters and setters are evil if used excessively (by that I mean, when it's not necessary and would break the business model), but why shouldn't we have a function called GetBalance()?

Surely this would be far more versatile than PrintBalance(); what if I wanted to show it to the user in another way than as the class wanted me to? Now, in some sense GetBalance() may not be relevant enough to argue that "getters and setters are good" because it doesn't (or maybe, shouldn't) have an accompanying setter, and speaking of which, a function called SetBalance(float f) could be bad (in my opinion) because it would imply to the implementer of the function that the account must be manipulated out side of the class, which is not a good thing.

Answer 1

I'd argue that providing accessors are more important in C++ than in C#.

C++ has no builtin support for properties. In C# you can change a public field to a property mostly without changing the user code. In C++ this is harder.

For less typing you can implement trivial setters/getters as inline methods:

class Foo { public:     const std::string& bar() const { return _bar; }      void bar(const std::string& bar) { _bar = bar; }  private:     std::string _bar; }; 

And don't forget that getters and setters are somewhat evil.