Using Private Data in Copy and Move Constructors

[Sh0es]

How do I implement t copy and move constructors without providing methods to access private data I want to remain "behind the scenes?"

[jlb]

Since constructors class members they can see every class variable no matter what section of the class the variables are in (private, protected, or public).

[Sh0es]

So are you saying that I could just define a constructor as:

Object::Object(const Object& copy)
{
	x = copy.x;
	y = copy.y;
	z = copy.z;
}

even if x, y and z are private members of Object

If that's not the case, then you misunderstand what I'm asking for. I want to know how I can access private members of copy without having to provide methods, if possible.

[Repeater]

That is the case.

Any object of type className can access the private variables of any other object of type className.

[Sh0es]

Alright then. Can I do the same with overloaded assignment operators?

[Repeater]

Any class function you like.

[Sh0es]

Alrighty then. This has been eye-opening since this kinda breaks the rules of encapsulation, but then again it seems to be a rule that C++ just ignores elements of OOP that are too hard to implement.

[Repeater]

See also Java and C#, which behave similarly.

[jlb]

Remember you're passing that parameter by a non-const reference.

This has been eye-opening since this kinda breaks the rules of encapsulation,

Some would argue that member functions of any kind break some of the rules of encapsulation, no matter what language you're using.

[Ganado]

I don't see how this breaks encapsulation; you're the one designing the intricacies of the class. You would have to know what's internally in the class to make any sense of a constructor, whether a "normal" constructor or a copy constructor.

Does this break encapsulation?

class Point {
  public:
    Point(double x, double y)
    {
        this->radius_squared = x*x + y*y;
        this->theta = atan2(y, x);
    }
    Point(const Point& other)
    {
        this->radius_squared = other.radius_squared;
        this->theta = other.theta;
    }
    double getX() {
        return sqrt(radius_squared) * cos(theta);
    }
    double getY() {
        return sqrt(radius_squared) * sin(theta);
    }
  private:
    double radius_squared;
    double theta;
};

I wouldn't say so. You, in order to make the constructor, have to know that internally it's the radius squared being stored. What makes the 2-arg constructor any better than the copy constructor, according to this logic? This isn't the most realistic or efficient example... but I think it shows the basic concept. The user doesn't know what the internal representation of the x and y are, and the user doesn't need to know that. But you, as the class designer, have to either way.

The user of the class still doesn't have to know about the inner details.

int main()
{
    Point point(3, 2); // normal constructor
    Point origin(0, 0);

    Point p3(point); // encapsulation is not being broken here anymore than above
    cout << p3.getX() << endl;
}

btw, point classes are sometimes simple enough such that the class designers just keep the x and y member variables public, such as in SFML. If the class is simple enough and is meant to just "hold data" instead of being a functional, independent object, then this can be okay.