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

Answer 1

The compiler will emit set_ and get_ if you define a property, so it's really just save some typing.

This has been an interesting discussion. This is something from my favorite book "CLR via C#".

Here is what I quoted.

Personally, I don't like properties and I wish that they were not supported in the Microsoftm.NET Framework and its programming languages. The reason is because properties look like fields but they are methods. This has been known to cause a phenomenal amount of confu-sion. When a programmer sees code that appears to be accessing a field, there are many assumptions that the programmer makes that may not be true for a property. For example,

• A property may be read-only or write-only; field access is always
  readable and writable. If you define
  a property, it is best to offer both
  get and set accessor methods.

• A property method may throw an exception; field access never throws
  an exception.

• A property cannot be passed as an out or ref parameter to a method; a field can.

• A property method can take a long time to execute; field access always
  completes imme- diately. A common
  reason to use properties is to
  perform thread synchronization, which can stop the thread forever, and
  therefore, a property should not be
  used if thread synchro- nization is
  required. In that situation, a method is preferred. Also, if your class can be accessed remotely (for example,
  your class is derived from
  System.MashalByRefObject), calling
  the property method will be very
  slow, and therefore, a method is
  preferred to a property. In my
  opinion, classes derived from
  MarshalByRefObject should never use
  properties.

• If called multiple times in a row, a property method may return
  a different value each time; a
  field returns the same value each
  time. The System.DateTime class has a read- only Now property that returns
  the current date and time. Each time you query this property, it will
  return a different value. This is a
  mistake, and Microsoft wishes that
  they could fix the class by making
  Now a method instead of a property.

• A property method may cause observable side effects; field access never does. In other words, a user of a type should be able to set various
  properties defined by a type in any
  order he or she chooses without
  noticing any different behavior in
  the type.

• A property method may require additional memory or return a
  reference to something that is not
  actually part of the object's state, so modifying the returned object has
  no effect on the original object;
  querying a field always returns a
  reference to an object that is
  guaranteed to be part of the original object's state. Working with a
  property that returns a copy can be
  very confusing to developers, and
  this characteristic is frequently not documented.