Re: Any dot-operator proposals out there?
Patrik Kahari wrote:
This only is a problem if one estimates that classes overloading
operator.() would still have other public members that client code is
supposed to access. I would call that hypothesis into doubt.
Well, here are my two cents worth..
If no addition to the public interface is allowed then the wrapper
object is nothing more than the object it wraps as far as the client
is concened. I think that would be a too serious limitation. A client
could want to use such a wrapper object precicely because of the
additional interface of the wrapper. As in the wrapper would be
something more than the object it wraps (from the clients
perspective).
I was thinking more of use cases where we don't want that. e.g.,
smart-references as return types of smart-pointers or proxy objects to be
returned by, say operator[] in a map. In this case, the returned object
should be as close as possible in behavior to the object it wraps.
An example; Say a client wants to keep count of how many objects of
some built in type are created in his system. He creates a wrapper
type to keep a static count. He needs a public interface for clients
to get to the count.
This particular use case is not convincing because the access to the static
count should probably happen through a static function. However, I maybe
misunderstanding; do you mean something like this:
template < typename T >
class counting_wrapper {
static
unsigned long & count ( void ) {
static unsigned long the_count = 0;
return ( the_count );
}
T the_data;
public:
counting_wrapper ( T const & val = T() )
: the_data ( val )
{
++ count();
}
counting_wrapper ( counting_wrapper const & other )
: the_data ( other.val )
{
++ count();
}
~counting_wrapper ( void ) {
-- count();
}
operator T & ( void ) {
return ( the_data );
}
operator T const & ( void ) const {
return ( the_data );
}
static
unsigned long get_count ( void ) {
return ( count() );
}
// overloaded dot-operator missing.
}; // counting_wrapper
You would just use counting_wrapper<some_type>::get_count() to get the
count. I don't see why there would be a need for a member function that
could be shadowed by overloading the dot-operator.
n1671 addresses that: you _can_ get at the count member, e.g, via
(&ws)->count. Using boost::addressof, you can do
(addressof(ws))->count
even when operator& is also overloaded. The proposal also discusses other
ways of accessing the member.
Thus, the problem is not that certain members are inaccessible, it is
that getting at them requires a new batch of idioms. Since I would
estimate that most classes defining their own operator.() have little to
no use for other public members, I would be willing to put up with the
slight syntactic inconvenience.
Having a client write (&ws)->count, instead of ws.count, would mean
the clients would have to understand the inner workings of the wrapper
(that the dot operator is overloaded). That seems to violate the
principle of encapsulation.
No it does not. If the client thinks of the wrapper as _more_ than the
wrapped object, it knows that it deals with the wrapper. If the client is
written under the assumption it deals with the wrapped object, it has no
need for additional members.
I dont think its unreasonable to excpect a uniform syntax to get to an
objects public interface. Writing dot for most objects and having to
write (&x)-> for others (or even (addressof(x))->) would be a
confusing inconsistency.
As I said, I do not yet see use cases where one would overload the
dot-operator _and_ have member functions.
The N1671 you mention has a suggested solution: "Apply operator.() if
only there is no matching function". That sounds a reasonable solution
to me, although there would still be a problem that functions would
not be forwarded if there was a named function of the same name in the
wrapper also.
If I recall correctly, n1671 recommends a different proposal. You quote from
the section "Alternative Proposals". Unless I see a convincing use case, I
would rather go with n1671 as it stands. (Although, I would not really care
that much since I do not plan on putting members other than operators
within a class that overloads the dot-operator.)
However, any of the proposals is better than not being able to overload the
dot-operator at all.
Best
Kai-Uwe Bux
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]