Article View: comp.std.c++
Article #3091Re: Give operator. a chance
From: David Byrden
Date: Mon, 22 Jan 1996 19:50
Date: Mon, 22 Jan 1996 19:50
65 lines
2802 bytes
2802 bytes
Dan;
>> Is operator.() banned from the standards discussion?
No, but the time for public contributions to the standards discussion
ended over 6 months ago.
>> Ideally, operator.() should allow you to have all the things
>> inheritance allows you to have, except for storage. I.e. a class
>> with operator.() should behave just as its "base class", but be
>> allowed to override suitable functions.
>> Why isn't this possible? What's the catch?
New facilities are not added to the C++ language when their effect can be
attained by a little programming using existing facilities.
From your description, it seems to me that an your operator.() object
method would return a reference to another object, and the named member
function would be called in that object. For example, here is class
Handle acting as a proxy for a class Bitmap;
Handle h ; // class Handle overloads operator.()
h.display() ; // h returns a reference to a Bitmap object
// whose display() is then called
Operator.() was not overloaded because you can achieve exactly this same
effect without it, if the clas Handle has a set of member functions
matching those in Bitmap, The Handle member functions can simply make
inline calls to the Bitmap member functions; they can also override to
change behaviour where necessary:
class Handle {
Bitmap & ref ;
public:
bool display()
{
return ref.display() ;
}
} ;
Various implementations of this kind of scheme are described in the
literature, for example Coplein, My favourite implementation is where the
handle class, and the genuine class, both inherit their interface from
the same abstract base class.
David Byrden
|| C++ training for professional programmers ||
|| My opinions ARE those of my employer. ||
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID:
<4e0pj1$rq6@news.bridge.net>Path:
arc1-ca.pugleaf.net!engnews1.Eng.Sun.COM!taumet!clamageReferences:
<3102AD11.1663@et.se>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!engnews1.Eng.Sun.COM!taumet!clamage From: David Byrden <100101.2547@compuserve.com> Newsgroups: comp.std.c++ Subject: Re: Give operator. a chance Date: 22 Jan 1996 19:50:27 GMT Organization: self-employed Approved: clamage@eng.sun.com (comp.std.c++) Message-ID: <4e0pj1$rq6@news.bridge.net> References: <3102AD11.1663@et.se> NNTP-Posting-Host: taumet.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Nntp-Posting-Host: ppp-mia1-45.bridge.net X-Mailer: Mozilla 1.1N (Windows; I; 16bit) X-Lines: 61 Content-Length: 1888 Originator: clamage@taumet