From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-04 07:35:45
In message <01a101c01669$12b67b20$3e0524d4_at_pdimov>, Peter Dimov
>It is not the inclusion itself I am discussing, but its form. any_cast is a
>free function, why not make copy_to a free function as well?
The case for any_cast as free function is much clearer: Its intended use
as a cast-like function. Form follows function.
>> >This makes copy_to even more generic.
>> I don't see that this actually buys me very much.
>Offhand I don't see the exact benefits either, but the users may find an use
>for this idiom. Genericity is good, unless there are strong reasons against
I'm not keen on bells and whistles for their own sake, which is what
this sounds like.
>to_ptr((T*)0) is an unsupported 'hack' for MSVC users only; and while
>definitely 'ugly', it does no harm to the 'any' concept.
Judging by the recent discussion re VC7 it is a long term hack. If
someone wished to make their code portable, they would rely on that
hack, and away you go: permanence.
>> By providing my own function object type.
>You're still free to do that, if you don't like the default. If you can
>propose a better default, I'll be glad to consider it.
The point I am making is that there is no reasonable default, therefore
one should not be provided. For the same reason that type_info does not
support operator<, neither should ref. operator== makes sense, but
unless you actually have a proper ordering, operator< should be omitted
in favour of providing the user with a named, documented ordering
function object type.
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk