   Why Get/Set Functions?
  I can't understand what the purpose of a Get/Set function would be in C++.  If you're going to make a private variable 'x' and also add GetX() and SetX() functions, why not just make 'x' public?Thanks   
  What if X represents a height which cannot be negative? Your setHeight could verify that the given value is above 0, otherwise default it to 1 or do nothing and return an error code.   ;Quote:Original post by kordovaWhat if X represents a height which cannot be negative? Your setHeight could verify that the given value is above 0, otherwise default it to 1 or do nothing and return an error code.Mmmm...  Makes sense.  I can't believe I never thought of that.  Thanks!;  +++understandable code, consider the following ----CMyclass global;global.m_x = 32;----------------CMyclass global;global.SetHeight(32);;  http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=78&rl=1Consider the following where m_x is safe from being changed by a get function and set does some checking.class foo{public:foo(int x): m_x(x){}//pass const ref.int const & get_x_ref()const {return m_x;}//pass const ptr to const int.int const * const get_x_ptr()const {return &m_x;}//pass a copy.int get_x()const {return m_x;}void set_x(int& const new_x){if(new_x > m_x)m_x=new_x;}private:int m_x;};;  And mabye you'll need to do something when the variable is changed (or even read, mabye).However, the OOP-reasoning behind this is that it hides how it's actually implemented. The setHeights() function would hide whether it's a linked list, a vector, a static array, or some other container that is storing the heights. If you realize that you need random access to the heights, you can easily swap to a vector from a linked list without the use ever knowing.Set/getss aren't fool-proof; used too much usually indicate a bad design.[Edit: Oops, it's 'OOP' not 'OPP'.]   ;  [correction]Quote:void set_x(int const& new_x){if(new_x > m_x)m_x=new_x;};Quote:Original post by EzbezSet/getss aren't fool-proof; used too much usually indicate a bad design.I don't agree. Even experienced programmers are not always able to foresee how a project develops and at some point you might need validation routines for something trivial that you have been accessing and changing directly before.And - this might be just personal preference - I find it easier to spot such methods being used in code than when public object variables are being accessed which makes code easier to read for me (especiall if it's not mine).This only applies to "set-methods" though unless you are working on array/vector type of variables.Most reasons for the use of set/get methods has already been mentioned, I would just add multi threaded application programming (critical resource access) to the list.   ;  As I said in the other thread, without language support for get/set properties (which I wish were going to be implemented in C++0x), we can emulate them with nested classes. The good point about that is that we create a new type that we can use in other places that encapsulates the logic to enforce the particular invariant. The responsibility is now the contained type's, not the container's.class foo{public:foo() : height(0) {}foo(int h) : height(h) {}class bar{public:bar(const int& x) : m_x(x) {}operator const int() const { return m_x; }bar& operator = (const int& x){if(x <= m_x)throw std::runtime_error("Invalid value for bar");elsem_x = x;}private:int m_x;};bar height;};// Then we get to use syntax like:foo a; // a.height == 0a.height = 10;a.height = 20;a.height = 15; // throws an errorAnother idea would be to use assert() instead of throw()   ;Quote:Original post by Brocketino+++understandable code, consider the following ----CMyclass global;global.m_x = 32;----------------CMyclass global;global.SetHeight(32);You compare completely dissimilar levels of self documenting code, if those are supposed to be the same thing.The correct comparison would be something like:Public    Accessorglobal.x = 42; global.setX( 42 );global.height = 42; global.setHeight( 42 );I understand the first more intuitively, because I don't need to do the full lingual grok and effectively translate back into the first.  This is because I'm used to recognizing {var} = {value}, but not {var}.set{property}( ${value} ) - namely because "Set ${property}" is woefully inadequate a description for the majority of "accessors" in my classes, so it ends up a lot less used.Compare:  SetSize to Resize.The subject of "Set the size of the array to 42" is the size.  SetSize focuses on the property, directing attention to it (and away from the class in general).The subject of "Resize the array to 42", on the other hand, is the array.  This focuses on the class itself, and things like it's (potentially conditional) invariants.  I'd be less likely to remember that my iterators are invalidated were I using std::vector<T>::setsize instead of std::vector<T>::resize.   