Should I use reference member to deal with dependency between objects?

Question

As a beginner in C++, I am practicing C++ with an algorithm assignment. Along the way, I have some questions that I have difficulty getting through. Pardon me if the questions sound entry-level since I am still learning.

The goal is to find collinear points in a given vector of points with three classes. The following briefly describes the three classes' purposes:

1. Point: Representing a point with x and y values.
2. LineSegment: Representing a line segment with two points at ends.
3. Collinear: Containing the segments found in a vector of Points. The main part of the algorithm.

So, I would expect the client code to look like this:

std::vector<Point> points;    // may become huge
// populate points
// ...

Collinear collinear_points(points); 
std::vector<LineSegment> segments_in_points = collinear_points.GetSegments();

Since the class Collinear depends on a certain vector of points to get the segments correspondingly, I think it would need it as a data member. The question that keeps haunting me is, should it hold a copy of the vector or hold a raw pointer/reference to the vector outside the object. I think a smart pointer would be an overkill here. According to the old answer here, maybe it is better to go with reference which also avoids potential expensive copying? What is the common practice for this kind of dependency between classes if any exists?

If points gets modified after the construction of collinear_points, then the data collinear_points is referencing will be inconsistent with the segments it contains. Is it common to leave the responsibility to users for making sure the validness of an object depending on other ones? Is there a way to let collinear_points know the content has been modified and put it in an invalid state?

Answer 1

To answer your actual question from the title: A non-owning raw pointer would still be the usual choice, mainly because that’s what we’ve been doing since the old C days. Of course, a pointer has the problem that it can be nullptr. So using a reference communicates more clearly that null is not an allowed value. Because of that I tend to use the reference, although it still feels a tiny bit weird even to myself. But imo it’s the better design decision overall

That said, I believe the real question here is one of ownership. If Collinear does not own the vector, the user of your API has to make sure that the vector lives at least as long as the associated Collinear object. Otherwise you’ll access a dangling pointer/reference and things tend to go downhill from there. ;)

Is there a way to let collinear_points know the content has been modified and put it in an invalid state?

Yes, there is. Own everything. That includes the points vector and the segments vector. Following this approach Collinear could look something like this:

class Collinear {
public:
    // usings because I’m a lazy typer
    using PointsVec = std::vector<Point>;
    using SegmentsVec = std::vector<LineSegment>;

    // Take ownership of the points vector by either copying
    // or moving it into a member.
    explicit Collinear(const PointsVec& p): m_points(p) {}
    explicit Collinear(PointsVec&& p): m_points(std::move(p)) {}

    // Retain ownership of the segments vector by returning a const ref.
    const SegmentsVec& GetSegments(); // Check if you can make it const.

    // access functions for the two vectors ...
private:
    PointsVec m_points;
    SegmentsVec m_segments;
}

Now Collinear controls access to the points vector. You’ll have to write the functions for the permitted operations as members of Collinear. The important thing is never to return a non-const pointer or non-const ref to m_points, because then you might miss write accesses.

The segments vector is similar. Your provide the write access member functions and Collinear retains ownership, which means it can re-calculate it when necessary and the user doesn’t need to be concerned with that. Depending on how expensive the calculation is you can now go wild with lazy evaluation and every optimization you can think of.

There is a completely different design approach, though. Own nothing. Does Collinear have to be a class at all? Could it be a bunch of free functions in a namespace?

namespace Collinear {
    std::vector<LineSegment> GetSegments(const std::vector<Point>& points);
}

// ...

auto segments_in_points = Collinear::GetSegments(points);

That’s the opposite of the own-everything approach. Before, you had full control. Now your user has full control. On the other hand, they now have to take care of any laziness/optimizations/update detection.

Which approach is appropriate is a question of a) API design philosophy and b) your conrete situation. What are your users? What do they expect? Which approach makes their lives easier? Since this is an assignment, you probably won’t have any real users. So imagine a group of people that might want to use your code and decide based on that. Or just use the approach you’ll have more fun implementing. The important thing imo: Pick one of the two approaches. Don’t mix them, because such an API is inconsistent. That increases confusion, decreases ease of use, and makes errors more likely.

Btw:

I think a smart pointer would be an overkill here.

Using smart pointers is not a question of overkill. It’s a question of ownership. If you have an owning pointer never use a raw pointer for it. … Unless a legacy API forces you to. Even then it’s a great idea to mark it as owning with a transparent wrapper like gsl::owner<T>.

Answer 2

The question that keeps haunting me is, should it hold a copy of the vector or hold a raw pointer/reference to the vector outside the object

I think you should keep a copy of vector here to keep things generic.You don't want your collinear class depend on a particular vector<Points>, instead it should be like while creating instance of collinear class you just tell it on what vector<Points>, it has to work on.Then if you change this vector and you want collinear also to work on this data set(which you might not want), its your responsibility to tell collinear to work on new data set.If you want collinear to be updated automatically when you update vector<points>, you can do so, but you have to answer questions like what happens to the state of collinear(which would be depending on the vector<points>) when the data set changes.