Re: [boost] [challenge: Dynamic Overloads]

From: Marco (mrcekets_at_[hidden])
Date: 2007-10-11 16:07:35

On Thu, 11 Oct 2007 17:30:42 +0200, Michael Fawcett  
<michael.fawcett_at_[hidden]> wrote:

> 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

I understand your analogy but anyway if we agree that in your example
sets/includes "bar" discards "foo" automatically there is no ambiguity
that we have to check.
Then if you want only to state that this behaviour could be not obvious
for the user, I can only say that, IMO, this is more a documentation
than an implementation problem.

Marco Cecchetti

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/