🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #3091

Re: Give operator. a chance

#3091
From: David Byrden
Date: Mon, 22 Jan 1996 19:50
65 lines
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!clamage
References: <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