Re: [boost] Overloading operator. (was: Re: [flyweight] some minor comments)

From: Peter Bindels (dascandy_at_[hidden])
Date: 2007-12-20 16:16:33

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_at_[hidden]> 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
>