Friend function for overloaded operator

Started by
3 comments, last by Fruny 15 years, 1 month ago
I am not sure what this book is trying to get at because the friend function they describe seems to be incorrect. Here is what they ask you to do: friend istream& operator <<(istream& ins, double write_me) This function looks awfully strange to me because if this is suppose to be associated with a class doesn't if have to have a class as a parameter? So here is the class that this is suppose to be associated with and I have written all the other functions and they work properly but this one just makes me scratch my head and ask what the heck do they want.

#ifndef LIST_H
#define LIST_H

#include <iostream>
#include <fstream>
using namespace std;

struct node
{
	double item;
	node *next;
};

typedef node* nodeptr;

class List
{
public:
	List();
	void add(double i);
	double front();
	double back();
	double the_current();
	void advance();
	void reset();
	void insert(double after_me, double insert_me);
	void insert_here(nodeptr after_me, double the_item);
	friend ostream& operator <<(ostream& outs, const List& l);
	//friend istream& operator >>(istream& ins, double write_me);
private:
	nodeptr head;
	nodeptr current;
	int count;
};

#endif

Any help would be greatly appreciated.
Advertisement
They made a mistake there (I suspect that function is not even legal.) Just replace the double in that function with List const&
Humble people don't refer to themselves as humble (W.R.T. "IMHO".)
It will actually compile using those parameters but there is nothing you can do inside because everything that you try causes all kinds of errors :). So its "legal" to use that but absolutely useless because you have no access to anything other than the double being passed in which again doesn't do you much good. Just thought you should know that it does compile. Thanks for clearing that up I was pretty sure that was an error when I read it.
It is of no use in this class, but it is possible that you might use a friend function to access private static data in a class:

class x{private:    int v;public:    friend void print(){ std::cout << x::v << "\n"; }};int x::v=23;void f(){    print();}


This is a stupid example, but there could be situations where it would be of some kind of use, although generally friend functions that do not operate on a class instance would be a major alarm bell for dodgy design.

Plus for the above example, of course, you would be far better to just use a public static method.

toogreat4u is correct though - there is no actual enforcement for a friend function to take an instance of the class as a parameter, it is just very common. I would agree that the book almost certainly contains a typo.

PS: I hope if this book is showing you how to implement a linked list properly it moves on afterwards from all this internal state current(), advance(), reset() nonsense and shows you how to implement iterators. Having a list maintain its own internal "current" pointer breaks horribly if you try to iterate through the list in the middle of an existing iteration.

list a;void f(){    a.reset();    for(int i=0;i<a.count();++i)        {        if(a.current()==12.0)            {            a.reset();            for(int j=0;j<a.count();++j) a.advance(); // oh dear, broken            }        a.advance();        }}std::list<double> a;void f(){   for(std::list<double>::iterator i=a.begin();i!=a.end();++i)        {        if(*i==12.0)            {            for(std::list<double>::iterator j=a.begin();j!=a.end();++j); // no problem            }        }}
Quote:Original post by px
I suspect that function is not even legal.


It is legal. std::istream is a class. The List class is declaring that function to be its friend, which is fine even though that function won't take advantage of it.

But yeah, it looks like an error.


And incidentally, a using namespace std; in a header file is an ungodly abomination: you're polluting the global namespace for all the users of your header. Which is not nice.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

This topic is closed to new replies.

Advertisement