Returning pointer/ref to private member

Why is it legal for a class to have a public member function that returns a reference to a private member? Even though this would have to be part of the class definition, giving direct access to a private member variable undeniably violates encapsulation:

Code:

class
{
    private:
        mutable int hidden;
    public:
        int& unHide () const
        {
            return hidden;
        }
} thing ;

int main()
{
    // thing.hidden = 1; /* illegal */

    int& hidden = thing.unHide () ;

    hidden = 1;

    return 0;
}

Is there any legitimate reason for doing something like this?

You may want to be able to create a getter, but not a setter, to a class member, for which returning by value is inefficient.
The point is that private means the outside cannot access it. What the class does with it is up to itself. No sense for C++ to restrict your ability to do things on purpose.
You can also change your example to return a const reference.

It's legal, and yes, it breaks encapsulation, which is why it's generally discouraged.

That's the beauty about C++. It doesn't force you to do these things. The programmer should know that it is bad OO technique.

Originally Posted by sand_man

That's the beauty about C++.

When you end up working with legacy code and/or code written by others, it turns out to be more of a tragicomedy.

Originally Posted by CornedBee

It's legal, and yes, it breaks encapsulation, which is why it's generally discouraged.

How would you avoid it (if possible) in the following (stupid) sample:

Code:

class HouseDataBase
{
public:
   HouseList getHousesWithOpenDoors() const;
   setDoorClosed(int house_id);
...
};

class City
{
  HouseDataBase mHdb;

public:
  HouseDataBase& getHouseDb();
...
};

int main()
{
 City city;
...
city.getHouseDb().setDoorClosed(5);
...
}

Would you propagate the complete interface of the owned class HouseDb through class City? This could be a lot of (redundant) work (imagine more composition Classes like Streets, traffic lights, Cars,...)

Thank you!

Wouldn't it be better to create several classes such as House and Car and Light?
Then you create appropriate said house and add it to the city.
But you should also be able to fetch a house in a city and perform work on that one.
This sounds like a design I would use...

If I understand correctly, that can be resolved through private inheritance.

EDIT:
I don't understand correctly. Are you trying to implement an interface without exposing it to public?

If I understand correctly, that can be resolved through private inheritance.

I am not sure what is the problem in the first place. Private inheritance is not a solution here, since to follow pheres' example your City class should also provide a public getHouseDb() member function. If you can remove it in your example, then we can remove it in pheres' example, upon which private inheritance provides no advantage over composition in this case.

I'm not sure I would call a city a HouseDataBase either, so City is "not a" with the other class, in which case inheritance would be wrong.
But it is true that a City holds houses, so I would say that the current implementation of putting the House database inside the City is more correct.

I'm not sure I would call a city a HouseDataBase either, so City is "not a" with the other class, in which case inheritance would be wrong.

Private inheritance does not model "is-a", with respect to the public interface.

In an abstract sense, you can use private inheritance to model "has-a", which is why i suggested that in lieu of composition. Although, returning a reference to the privately inherited class defeats the purpose of this, as laserlight pointed out.

EDIT:
I think pheres' code is fine the way it is, although one may or may not want to make the City::getHouseDb() return a const reference.

I'd return a reference. Possibly const. But only if HouseDataBase is non-copyable.

Yes, this would mean that I must have an actual HouseDataBase object to back the reference, but I believe that would be a justifiable compromise in this situation.

Originally Posted by pheres

How would you avoid it (if possible) in the following (stupid) sample:

I'd refactor until it wasn't necessary.

Code:

class HouseDataBase {
public:
    void closeDoor(int houseId);
};

class City {
    HouseDataBase mHdb;
public:
    void closeHouseDoor(int houseId) { mHdb.closeDoor(houseId); }
};

int main()
{
    City city;

    city.closeHouseDoor(5);
}