Re: [boost] Re: Re: Re: more flexible any

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-09-03 08:41:46

On Tuesday 03 September 2002 04:16 am, Alexander Nasonov wrote:
> Douglas Gregor wrote:
> > any/dynamic_any starts losing its usefulness when we add more
> > requirements on the types contained in them.
>
> There is no additional requirements for contained types! I wrote about that
> in my other post:
> http://aspn.activestate.com/ASPN/Mail/Message/1343231
>
> The idea there is to compare any/dynamic_any with some type T:
[snip]

I completely misread your prior post. I understand your approach now, and I'd 
support the addition of operators != and == as described into 'any'.

As for the any_less function object: why not supply it as a specialization of 
std::less? Then we get set<any> for free...

> Douglas Gregor wrote:
> > It would, however, be _extremely_
> > interesting if one could extend any/dynamic_any in a way that supported
> > user-defined sets of operations on any/dynamic_any objects (e.g., one
> > might want !=, ==, *, and ++ defined to make 'any' work on input &
> > forward iterators). Might be able to do this by using mixins with virtual
> > functions...
>
> How? Using template parameters like this?
>
>   typedef dynamic_any<incrementable, equal_comparable> my_dynamic_any;

Yes. The idea is that my_dynamic_any will only be able to hold types that are 
incrementable and equality_comparable in this case.

> I see a problem here. How to invoke binary operation (==, !=, *) if two
> anys contain values of different type? Again by throwing?

Here it would be reasonable to throw. 

Here's the reasoning behind the idea: polymorphic adaptors provide a bridge 
between compile-time and run-time polymorphism. For instance, boost::function 
is a polymorphic adaptor for function objects, so one can transform code like 
this:

  template<typename Compare> void sort(Compare comp);

into non-template code like this:

  void sort(const boost::function<bool (int x , int y)>& comp);

The two functions are semantically very similar, except that the first is a 
template and the second is not, and therefore the decision between the two 
can be made based on the size vs. speed tradeoff.

All polymorphic adaptors could be used in this way, so the challenge would be 
to make an 'any' that is a polymorphic adaptor generator. Then we could have 
polymorphic adaptors for whatever concept we need, so that, for instance, we 
could develop with large template libraries more rapidly using these adaptors 
and separate compilation.

I'm not sure if it's entirely possible, but it really would be interesting :)

        Doug