From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-10-12 12:42:10
On 10/13/07, Michael Fawcett <michael.fawcett_at_[hidden]> wrote:
> On 10/12/07, Marco Costalba <mcostalba_at_[hidden]> wrote:
> > On 10/12/07, Marco Costalba <mcostalba_at_[hidden]> wrote:
> > >
> > > So I would say a _possible_ policy is to not allow to register say
> > >
> > > set(f6);
> > >
> > > if is already registered a function with a "compatible" signature.
> > >
> > This is wrong.
> > I would have said:
> > " a _possible_ policy is that a call like
> > f.set(f6);
> > overwrites any exsisting function with the same signature *or with a
> > compatible signature*"
> Why is that better than your original wording? Your latter
> description breaks from precedence set by std::set and map.
I don't think we have to follow the precendent by std::set and
std::map because of two very important reasons:
1.) The Boost.Overload implementaion does not follow the Contianer
concept -- not by a long shot. If at best, it's closer to an
std::pair<> than an std::map<> or std::set<>. This is because
Boost.Overload is not a container -- it never was, and it never will
2.) The concepts and the use cases for Boost.Overload are not meant
for run-time consumption: therefore throwing exceptions and runtime
dispatch is out of the question. This means doing a set(&foo1) is
better than saying insert(&foo1) because 'set' conveys better the
concept which Boost.Overload is making as compared to 'insert'. See #1
as to why this is the case.
Again, if you're looking for a container for runtime function objects,
see Boost.Signals and the (other) library I'm working on, the Runtime
Dynamic Dispatch Library. At best, you might want to consider an
std::map<> of Boost.Function objects instead.
I hope this makes things clearer.
-- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis_at_[hidden]] [+63 928 7291459] [+1 408 4049523]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk