Boost logo

Boost :

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


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,

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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at