2

My code was reviewed on: https://codereview.stackexchange.com/questions/3754/c-script-could-i-get-feed-back/3755#3755

The following was used:

class Point
{
    public:
    float   distance(Point const& rhs) const
    {
        float dx    = x - rhs.x;
        float dy    = y - rhs.y;

        return sqrt( dx * dx + dy * dy);
    }
    private:
        float   x;
        float   y;
        friend std::istream& operator>>(std::istream& stream, Point& point)
        {
            return stream >> point.x >> point.y;
        }
        friend std::ostream& operator<<(std::ostream& stream, Point const& point)
        {
            return stream << point.x << " " << point.y << " ";
        }
};

by another member. I don't understand what friend functions are doing. Is there another way to do this without making them friend functions? And how can the client access them when they are private using the following? Could someone expound on what exactly is being returned?

int main()
{
    std::ifstream       data("Plop");

    // Trying to find the closest point to this.
    Point   first;
    data >> first;

    // The next point is the closest until we find a better one
    Point   closest;
    data >> closest;

    float   bestDistance = first.distance(closest);

    Point   next;
    while(data >> next)
    {
        float nextDistance  = first.distance(next);
        if (nextDistance < bestDistance)
        {
            bestDistance    = nextDistance;
            closest         = next;
        }
    }

    std::cout << "First(" << first << ") Closest(" << closest << ")\n";
}
Community
  • 1
  • 1
Matthew Hoggan
  • 7,402
  • 16
  • 75
  • 140

3 Answers3

1

And how can the client access them when they are private using the following?

Yes. Since friend functions are not member of the class, it doesn't matter where you define them or declare them. Any can use them. The access rules don't apply on them.

Could someone expound on what exactly is being returned?

operator>>() returns std::istream& which is reference to input stream. And operator<<() returns std::ostream& which is reference to output stream.

Is there another way to do this without making them friend functions?

Yes. There is a way. You can add two member functions input and output to the public section of the class, which will do what friend functions are doing now, and you can make operator<< and operator>> non-friend functions as follows:

class Point
{
    public:
    //....
    std::istream& input(std::istream& stream)
    {
       return stream >> point.x >> point.y;
    }
    std::ostream& output(std::ostream& stream) const
    {
       return stream << point.x << " " << point.y << " ";
    }
    //...
};

std::istream& operator>>(std::istream& stream, Point& point)
{
  return point.input(stream);
}
std::ostream& operator<<(std::ostream& stream, Point const& point)
{
  return point.output(stream);
}
Nawaz
  • 353,942
  • 115
  • 666
  • 851
  • 1
    @ Nawaz Thanks, I need to go back and review Stroustrup's book. Do you understand the syntax for what is being returned? – Matthew Hoggan Jul 31 '11 at 06:46
  • 1
    @ Nawaz Thanks again, with that said, I understand the type being returned, but it is the semantic/functionality of what is happening by returning such a type. I am assuming that stream >> point.x >> point.y reads from the file opening in stream's constructor into the x and y member variables. But why return it, why not just leave it at that? – Matthew Hoggan Jul 31 '11 at 06:57
  • @Matthew: You return it show that you could write `stream << point1 << point2`, that is, you could use it in *chain* calls. – Nawaz Jul 31 '11 at 06:59
  • @Nawaz - I think the members should be named input and output rather than operator. – Bo Persson Jul 31 '11 at 10:40
  • @Bo Persson: Ohh..Yes. I forgot to change the names. – Nawaz Jul 31 '11 at 10:47
1

You can do this without friend functions by defining 'getters' for your X and Y member variables and an appropriate constructor, like this

class Point
{
public:
  Point(float xx, float yy) : x(xx), y(yy) {}

  float getX() const { return x; }
  float getY() const { return y; }
private:
  float x;
  float y;
};

std::istream& operator>>(std::istream& stream, Point& point)
{
  float x, y;
  stream >> x >> y;
  point = Point(x, y);
  return stream;
}
std::ostream& operator<<(std::ostream& stream, const Point& point)
{
  return stream << point.getX() << " " << point.getY() << " ";
}

Take your pick, both are valid.

Yakov Galka
  • 70,775
  • 16
  • 139
  • 220
jahhaj
  • 763
  • 4
  • 9
0

A friend function is independent from the class, but is allowed to access private members.

In your class there is no way to access x and y members (and that makes the class sort of useless, btw) so to be able to handle read/write of instances to a stream those functions had to be declared friends.

If you never saw the friend concept before then probably means you're trying to teach yourself C++ by writing code. This is an horrible idea... C++ cannot be learned that way for many different reasons.

Pick a good book and read it cover to cover and then experiment with it. It's by far the fastest (only) way.

It doesn't matter how smart you are (actually the smarter you are and the harder will be to learn C++ by experimentation: logic is not always an help in this place).

Community
  • 1
  • 1
6502
  • 112,025
  • 15
  • 165
  • 265
  • "If you never saw the friend concept before then probably means you're trying to teach yourself C++ by writing code. This is an horrible idea... C++ cannot be learned that way for many different reasons." I have seen friend before, I have used a few times but not 100% familiar with its semantics. I have also read quite a bit of C++. I read then play, read some more then play. However, I am finding that input from others in the industry helps out a lot. I have no real life experience outside of school with C++ so I am still learning. Thanks for you input though. – Matthew Hoggan Jul 31 '11 at 06:59
  • The `play` part is of course very very important; one will learn 10 times more about a concept by reading/writing than by just reading. The problem with C++ is that however in quite a few places the language is "illogical" (mostly for historical reasons) so logic deduction will not help at all and will misguide you. This fact combined with main philosophical idea of C++ that programmers make no mistake (therefore we have "Undefined Behavior daemons" instead of "Runtime Error angels" in C++) should make clear why experimenting-only is a suicide. – 6502 Jul 31 '11 at 08:06