 <p>There are several reasons why returning references (or pointers) to the internals of a class are bad. Starting with (what I consider to be) the most important:</p> <ol> <li><p><strong>Encapsulation</strong> is breached: you leak an implementation detail, which means that you can no longer alter your class internals as you wish. If you decided not to store <code>first_</code> for example, but to compute it on the fly, how would you return a reference to it ? You cannot, thus you're stuck.</p></li> <li><p><strong>Invariant</strong> are no longer sustainable (in case of non-const reference): anybody may access and modify the attribute referred to at will, thus you cannot "monitor" its changes. It means that you cannot maintain an invariant of which this attribute is part. Essentially, your class is turning into a blob.</p></li> <li><p><strong>Lifetime</strong> issues spring up: it's easy to keep a reference or pointer to the attribute after the original object they belong to ceased to exist. This is of course undefined behavior. Most compilers will attempt to warn about keeping references to objects on the stack, for example, but I know of no compiler that managed to produce such warnings for references returned by functions or methods: you're on your own.</p></li> </ol> <p>As such, it is usually better not to give away references or pointers to attributes. <em>Not even const ones!</em></p> <p>For small values, it is generally sufficient to pass them by copy (both <code>in</code> and <code>out</code>), especially now with move semantics (on the way in).</p> <p>For larger values, it really depends on the situation, sometimes a Proxy might alleviate your troubles.</p> <p>Finally, note that for some classes, having public members is not so bad. What would be the point of encapsulating the members of a <code>pair</code> ? When you find yourself writing a class that is no more than a collection of attributes (no invariant whatsoever), then instead of getting all OO on us and writing a getter/setter pair for each of them, consider making them public instead.</p>