Re: Any dot-operator proposals out there?
Patrik Kahari wrote:
I've occasionally wanted to be able to override the dot-operator [...]
My search for a proposal to add support for this operator has been
without success, however, and I wonder why.
Yes, In "the design and evolution of c++" Bjarne Stroustrup describes
why he did not allow it.
If i remeber correctly the resoning goes something like this;
The biggest need for a dot operator would probably be the
implementation of wrapper objects that would behave just like the
object it wrapped. As in the dot operator would return a reference to
the underlying wrapped object and not to the wrapper itself. But then
there would be no way for a client to access any methods or data of
the wrapped object itself. We can just overload the -> operator
instead and avoid the problem.
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.
An example:
<CODE>
#include <iostream>
template <typename T>
struct Wrapper {
Wrapper(T t):t_(t), count(0) {}
T* operator->() {
++count;
return &t_;
}
/*
T& operator.() {
++count;
return t_;
}
*/
size_t count;
T t_;
};
inline void test () {
std::string s("test");
Wrapper<std::string> ws(s);
int length = ws->length();
int count = ws.count;
/* if we had overloaded the '.' operator instead of the '->' operator,
we would have no way to get access to the 'count' member */
}
</CODE>
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.
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 ]