Re: [boost] [challenge: Dynamic Overloads]

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-10-11 11:30:42

On 10/11/07, Marco <mrcekets_at_[hidden]> wrote:
> On Tue, 09 Oct 2007 19:15:27 +0200, Michael Fawcett
> <michael.fawcett_at_[hidden]> wrote:
> > On 10/9/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> >>
> >> I thought about this, and the only problem is that it assumes that
> >> 'include' does not replace the already existing mapping between a
> >> function signature and the actual function being 'included'. Consider:
> >>
> >> void foo(int) { };
> >> void bar(int) { };
> >>
> >> overloads<void(int), void(std::string)> functions;
> >>
> >> functions.include(&foo);
> >> functions.include(&bar);
> >> functions(1); // will imply that 'foo' and 'bar' will both be called
> >>
> >> The above code suggests that functions(1) should call both foo and
> >> bar, because both functions are included in the overload set.
> >
> > It doesn't suggest that to me.  If we were talking normal overload
> > sets, it would fail to compile because it was ambiguous.  The user is
> > trying to introduce an ambiguity with the second include line, and
> > he's ignoring the return value, which I presume contains 'false', as
> > in, not inserted.
>
> Not sure, but maybe we're speaking of different "overloads".
> The overload implementation that I, Marco Costalba and Dean Michael Berris
> are working on is a multi-signature wrapper of boost.function.
> The assignment of a functor target mimic the behavior of boost.function:
> deduced the matching signature the new functor is assigned and the old one,
> if present, is discarded.
> At invocation time the implementation relies directly on standard
> C++ overloading,
> and mimic its behaviour.

Yes, I understand that.  I was talking about the same thing, only
making an analogy to classic overloading.  One would not expect the
following to compile:

void foo(unsigned char c) { }
void foo(signed char c) { }

foo(1);

Just like one shouldn't expect the following to run without error:

void foo(int) { };
void bar(int) { };

overloads<void(int), void(std::string)> functions;

functions.include(&foo);
functions.include(&bar); // return value signifies that ambiguity was
resolved by the overloads class, but user ignored it
functions(1);

In both cases you are introducing an ambiguity.  In one case the
compiler refuses it, in the other, your overloads class enforces it.

I chose 'include' because people often talk in terms of "being
included or excluded from the overload resolution set", so 'include'
felt right.

Hope my reasoning is clearer now,

--Michael Fawcett