Boost logo

Boost :

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2007-12-17 10:36:25


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk