🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.lang.c++
Article #238

Re: Cornell Bug Report #0 of 4

#238
From: m.terribile
Date: Wed, 25 Jun 1986 19:11
53 lines
2628 bytes
> Gripe #2:
> It seems that I am always needing to declare a function in one class
> as the friend of another class, while also needing to declare a function
> in the second class as a friend in the first.  C++ squawks because it
> needs to have the class defined before it can have a function in it
> declared as a friend in another class.  Needless to say, it is impossible
> to declare each class before the other.  So...
> 	1) Does this indicate lousy programming practices on my part?
> 	2) Do lots of other people also run into this?
> 	3) Is there a way to do this that I haven't figured out?
> 	4) Is this something that can't be helped or is a fix on the way?

My personal opinions:

	No, it's not lousy programming practice.  I just missed it, and I
thought it was legal.  In fact it's not -- the example below fails as
indicated, and I think that it addresses a rather common problem.

	Is there a way around it?  Yes.  It's ugly as sin and not half as
much fun.  You should be able to declare the entire second class as a friend
of the first.  ``friend class c2;''

	As far is there being a possible fix ... I think that we have to
ask Bjarne.  I'd like to see it work in the obvious way.  If it can't be
done for all member functions, then I'd like to see it at least work for
constructors (see the example).  I suspect that the fix will involve adding
another hyperfine level of sophistication to cfront, but I don't know, not
having studied cfront.

class	c2;	// c1 and c2 are alternate representations ... one is packed
		// for storage and one is unpacked for reasonable coding usage.
		// Much stuff omitted ...

class	c1
{
  public:
	c1( c2 );		// This is legal.
	friend	c2::c2( c1 );	// This is not!
};

class	c2
{
  public:
	c2( c1 );
	friend	c1::c1( c2 );
};
-- 

	from Mole End			Mark Terribile
		(scrape .. dig )	mtx5b!mat
					(Please mail to mtx5b!mat, NOT mtx5a!
						mat, or to mtx5a!mtx5b!mat)
    ,..      .,,       ,,,   ..,***_*.
Technical Details
Message-ID: <1375@mtx5a.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtune!mtunf!mtx5c!mtx5d!mtx5a!mat
References: <498@batcomputer.TN.CORNELL.EDU>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mtx5a.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtune!mtunf!mtx5c!mtx5d!mtx5a!mat
From: mat@mtx5a.UUCP (m.terribile)
Newsgroups: net.lang.c++
Subject: Re: Cornell Bug Report #0 of 4
Message-ID: <1375@mtx5a.UUCP>
Date: Wed, 25-Jun-86 15:11:20 EDT
Article-I.D.: mtx5a.1375
Posted: Wed Jun 25 15:11:20 1986
Date-Received: Fri, 27-Jun-86 06:51:24 EDT
References: <498@batcomputer.TN.CORNELL.EDU>
Organization: AT&T Information Systems, Middletown, NJ 07748-4801.
Lines: 53