Hi, When ignoring the metaprogramming part, an operator. is also interesting for generic proxies and mocks. It does give a few bumps along the road in terms of "what if operator. invokes operator." or "what if the returned function + object again have an operator.", but I think that's possible. The main problems are 1. people assume you want an operator. that does what operator-> does but with a reference 2. people stubbornly insist this isn't practical or needed so I doubt you'll be able to get anywhere. I hope so though, as I would like a generic mock / proxy class. Regards and good luck, Peter On 17/12/2007, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Sorry for this off-topic message, but I thought discussing overloading of operator. could be interesting.
Thorsten Ottosen wrote:
PS: what a shame we can't overload operator.() in C++
I think most of the proposals that have been made are quite wrong in their approach. They usually simply forward operator. to a reference.
While this is enough for things that only require forwarding, (like flyweight does) it is not a generic solution. It cannot be used with variant, for example.
First, what is the type of the right operand of operator. ? A name, a compile-time string, plus some eventual arguments if it's a member function call. mpl::vector_c<char, ....> is quite what we need.
Then, we need the ability to call a member from its name, and that requires some kind of compile-time reflection. Here again, mpl helps to build the structure of the reflection information.
template <typename T> struct reflection { };
template<> struct reflection<MyClass> { typedef mpl::map< mpl::pair< mpl::vector_c<char, 'm', 'e', 'm', 'b', 'e', 'r', '1'>, a_function_object_type /* the type could contain additional information about the available signatures */ >, .... > members;
typedef .... typedefs; typedef .... static_members; };
(all public members could be listed, including inherited ones)
This solution would be best, but since it is meta-programming intensive, requires usage of type containers, and is not easy to code with, I doubt the standard will want to adopt it.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost