Re: [boost] "any" suggestions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-14 08:48:39

From: "Kevlin Henney" <kevlin_at_[hidden]>
> Peter Dimov writes
> >From: "Kevlin Henney" <kevlin_at_[hidden]>
> >> In message <003001c10c2c$7faf3e10$2101bf0a_at_[hidden]>, Corwin Joy
> >> <cjoy_at_[hidden]> writes
> >> >Proposal 1:  A second "any" class which I will call anyx (for "any"
> >> >eXtractable).
> >[...]
> >> >...skip the obvious implementation with virtual functions etc...
> >>
> >> Actually, I don't think this is something that you can skip. What is
the
> >> "obvious" implementation? Output is trivial, [...]
> >
> >Not that trivial.
> >
> >struct X {};
> >
> >anyx a = X(); // error, no operator<< (std::ostream&, X const &);
>
> Of course this won't compile, nor is it supposed to. X does not satisfy
> the additional requirements that Corwin placed on the contents of anyx:
> support for << and >>.

Yes, you are right, I haven't made myself clear. The output is trivial given
these constraints, what is (relatively) non-trivial is to make the code
above compile but trying to output 'a' fail at runtime.

Of course the input parser that would have to be built in order to determine
the type is much more interesting. :-)

> I think you may have missed the following snippet
> in Corwin's proposal:
>
> >The disadvantage of course is that the held type must support istream
> >and ostream operators for "anyx" to work.

No, I did not, I simply don't like the cost of the requirement, that's all.
:-)

--
Peter Dimov
Multi Media Ltd.