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.