|
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