Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-31 05:07:11

In message <01fd01c012b7$64816290$3e116e97_at_[hidden]>, Ed Brey
<brey_at_[hidden]> writes
>Why is there not a non-const version of to_ptr?

Historical oversight: the original any had no direct access to its
content, and so when adding to_ptr I was still in that frame of mind.
Now added (and uploaded), thanks.

>How about a cast member function to complement the any_cast global:
>class any { ...
> template<ValueType>
> ValueType cast() const;
>};
[...]
>You almost could get rid of any_cast altogether by doing
> int i = any("3").cast<int>();
>instead of
> int i = any_cast<int>("3");
>
>except I do like how the bottom one looks.  I'm not entirely sure where
>any_cast would be used versus other casts.  I assume it comes into play once
>people start defining any-compatible conversions on their classes.

I toyed with the idea of a member cast op, but the duplication seemed
unnecessary and the any_cast syntax more intuitive.

>I did some hacking to get any to work on VC6SP4.  Here's what I did:
[...]

Thanks! I'll have a look at this.

>Another choice is to have to_ptr provide the pointer via a reference
>parameter, like copy_to does with the value; however, I'm wary of that idea
>since it starts bending our design to appease a broken compiler, which I do
>not like.

Another choice is to not to support to_ptr at all for VC, ie let them
eat copy_to, and reorganise internals accordingly. In this way no
interface backward compatibility issues arise.

>In the section "ValueType requirements", there is an extra "s" at the of
>"Another distinguishing features".

Thanks.

>I'd prefer to avoid using coding styles in documentation that cause problems
>in the real world.  In particular, I'd like to see the explicit std:: and
>boost:: scoping used.  Also, in count_all(), instead of further engraining
>std::endl, perhaps something like:
>
>cout <<
>    "#empty == " << count_if(values.begin(), values.end(), is_empty) << "\n"
>    "#int == " << count_if(values.begin(), values.end(), is_int) << "\n"
>    "#const char * == " << count_if(values.begin(), values.end(),
>is_char_ptr) << "\n"
>    "#string == " << count_if(values.begin(), values.end(), is_string) <<
>'\n';

I genuinely don't feel this to be a big issue for example code, as long
as the lib code itself is clean. However, if others disagree with me, it
may be something for documentation guidelines.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________