title: Are get and set functions popular with C++ programmers?
body: <p>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.</p>
  <p>Here's the C# 2.0 code:</p>
  <pre><code>public class Foo
  {
      private string bar;
  
      public string Bar
      {
          get { return bar; }
          set { bar = value; }
      }
  }
  </code></pre>
  <p>Or, in C# 3.0:</p>
  <pre><code>public class Foo { get; set; }
  </code></pre>
  <p>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.</p>
  <p>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#.</p>
  <p>Anyway, here's the C++ from what I gather:</p>
  <pre><code>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-&gt;' is good practice.
      this-&gt;bar = bar;
  }
  </code></pre>
  <p>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:</p>
  <pre><code>class Foo
  {
  public:
      std::string Bar;
  }
  </code></pre>
  <p>From what I gather, these are the advantages:</p>
  <ul>
  <li>You can change implementation details for the get and set functions, so instead of returning a private field you can return something more interesting.</li>
  <li>You can remove a get/set later on and make it read/write only (but for a public facing interface, this seems, not good).</li>
  </ul>
  <p>And the disadvantages:</p>
  <ul>
  <li>Takes ages to type, is this <em>really</em> worth the effort? Generally speaking. In some cases, the advantages make it worth the effort, but I mean, speaking in terms of &quot;good practice&quot;, is it?</li>
  </ul>
  <h3>Answer:</h3>
  <p>Why did I choose <a href="https://stackoverflow.com/questions/737409/are-get-and-set-functions-popular-with-c-programmers/737437#737437">the answer with less votes</a>? I was actually very close to choosing <a href="https://stackoverflow.com/questions/737409/are-get-and-set-functions-popular-with-c-programmers/737552#737552">veefu's answer</a>; however my personal opinion (which is apparently controversial), is that the answer over egged the pudding.</p>
  <p>The answer I chose, on the other hand, seems to argue both sides; I think getters and setters <em>are</em> 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 <code>GetBalance()</code>?</p>
  <p>Surely this would be far more versatile than <code>PrintBalance()</code>; what if I wanted to show it to the user in another way than as the class wanted me to? Now, in some sense <code>GetBalance()</code> may not be relevant enough to argue that &quot;getters and setters are good&quot; because it doesn't (or maybe, <em>shouldn't</em>) have an accompanying setter, and speaking of which, a function called <code>SetBalance(float f)</code> 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.</p>