On 14 mei, 08:12, Erik Wikstr=F6m <eri...@student.chalmers.se> wrote:
There are two reasons against it that I know of, the first being that
the general consensus in the standard committee is that it might
introduce too much trouble* , since a user would never know what will
happen if he uses the .-operator, the second is the problem you
mentioned about how to implement the normal behaviour. I know of no
convincing reason for allowing it since it really would not enable
behaviour that can't be simulated in other ways.
I was thinking of a few things in particular, mainly allowing
transparent forwarding of interfaces. Given variadic templates and an
overloadable operator. you could define a function as such:
template <typename R, typename... Argtypes>
auto operator.(std::string funcname, Argtypes... args) { return
memfun(this, new gen_send<R, ArgTypes...>(funcname); }
template <typename R, typename... Argtypes>
class gen_send {
private:
string funcname;
public:
R &operator()(Argtypes... arguments) {
// serialize and send
// wait for return value, return value
}
};
that would allow transparently forwarding of the function called,
irrelevant of which function it was. Marshalling the return type might
cause one or two small bits of trouble but I think there's a fairly
easy way around that.
* In fact a recent proposal (n2200) suggests that all operators,
except . (member selection), :: (namespace) and .* (memberpointer),
should be overloadable both as members and non member (that includes
new and delete).
Wouldn't that cause trouble with typeid and especially sizeof?
Ah, I missed those. I didn't read the whole of the proposal, but I