Article View: net.lang.c++
Article #238Re: Cornell Bug Report #0 of 4
From: m.terribile
Date: Wed, 25 Jun 1986 19:11
Date: Wed, 25 Jun 1986 19:11
53 lines
2628 bytes
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!matReferences:
<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