[boost] Re: [OBORONA-SPAM] Re: overloads-20050207.tar.gz

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-02-12 15:01:46

Alexander Nasonov wrote:
> Jonathan Turkanis wrote:
>> I assume you're using id<..>'s to distinguish signatures even if
>> they agree at every other position. My initial guess is that
>> operator()'s with the same id<..> would correspond to functions
>> having the same name. But then I see that each operator() seems to
>> have a unique id<..>, which make me wonder where the overloading is.
>
> All ids are unique. This is how I can deduce a signature of every
> function without ambiguity. Of course, these ids change original
> overloads relation between functions but you can "bring it back" at
> call time:
>
> Fsm fsm;
> fsm(enable_all(), Passive(), EvActivate());
>     ^^^^^^^^^^^^
> enable_all is not yet in tarball but it's very simple. You just make
> sure every id<N> has a constructor that accept enable_all.

Why is it called an overload set, then? Because all the functions are overloads
of operator()?

>> I'm not so sure I see how, or if, this relates to overload
>> resolution. In addition to the associative sequence operators, I
>> would expect to have a metafunction that takes an argument list and
>> determines which overload is called.
>
> Hmm, I'm not sure I can implemenent such metafunction because of
> complexity of C++ rules. I have to look at details.

I'm not really asking for you to provide this metafunction; I'm mostly trying to
figure out what your implementation of overload sets has to do with the overload
sets described in the standard.

Jonathan