Re: Additions to utility.hpp?

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-07-08 19:48:17

on 7/8/00 1:04 AM, David Abrahams at abrahams_at_[hidden] wrote:

> ----- Original Message -----
> From: "Daryle Walker" <darylew_at_[hidden]>
> 
>> I have suggestions to add classes to "utility.hpp."  They are like the
>> noncopyable class, except they are for the other automatic operators
>> (address and comma).
>> 
>> 1.  unaddressable
>> + blocks (unary) &
>> + has private declarations (within a class/struct) of
>> T* operator&();
>> T const * operator&() const;
>> 
>> 2.  default_inoperable
>> + blocks = & ,
>> + has private declarations (within a class/struct) of
>> T& operator=( const T& );
>> T* operator&();
>> T const * operator&() const;
>> T operator,( const T& ) const;
>> template <typename U>
>> U operator,( const U& ) const;
>> 
>> I don't know whether or not both forms of operators , or & are needed.  I
>> guess their (default) constructor and destructor would be protected and
>> inline and be defined to do nothing, like in noncopyable.
> 
> Interesting, but are they useful?

I'm not sure how useful they are.  Conceivably, the "unaddressable" class
could be used with a class that supposed to represent a temporary reference.
The "default_inoperable" class could be used if (for some reason) you don't
want any operators for an object.

For "default_inoperable," I saw a part in the 3rd edition of Stroustrup's
C++ book where he mentioned that classes get automatic operators = & and ,
by historical accident, and gave an example that blocks them (his prototype
list is simpler).  I just wanted to add that to Boost.

> It's easy to write a class whose default construction or copy-assignment
> semantics don't work right, but operator, and operator& pretty much always
> do the right thing. Do you have a motivating example for these?

No.  But remember, I'm not changing their semantics; I'm blocking them
totally.

--