Re: [boost] [type_erasure]bug:any(, binding<Concept>) can store wrong type

Subject: Re: [boost] [type_erasure]bug:any(, binding<Concept>) can store wrong type
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-08-23 10:14:55

On 08/14/12 09:37, Larry Evans wrote:
> On 08/13/12 11:16, Steven Watanabe wrote:
>> AMDG
>>
>> On 08/13/2012 09:06 AM, Larry Evans wrote:
>>> The attached runs OK without any compile or runtime errors.
>>> It seems to create a type_uns<1> from a type_uns<0> although
>>> there's no type_uns<1> CTOR for that.
>>>
>>> This sounds like another instance of the bug reported here:
>>>
>>> http://article.gmane.org/gmane.comp.lib.boost.devel/233101
>>>
>>> Is it?
>>>
>>
>> It's similar, but this is really undefined behavior,
>> since there's no way to detect the problem at compile
>> time.  It's also not necessarily possible to add an
>> assertion.
>>
> 
> What about detecting this "wrong type store" problem at run-time?
> That would be better than now where there's no indication of a problem
> either at compile-time or run-time.
> 
> I would think some sort of implementation of the visitor pattern would
> enable this.  IIUC, the visitor pattern enables reification of
> "abstract types" to "concrete types" which are then used to call a
> function taking those concrete types as arguments.
> 
> In type_erasure, "abstract types" corresponds to the placeholders and
> "concrete types" corresponds to the "actual types", as used here:
> 
> 
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost/type_erasure/any.html
> 
> To diagnose the "wrong type store" in the example program attached,
> maybe a binary visitor, something with a signature like the
> same_concrete in the attached, could be used.
[snip]
The attached, with a slightly modified same_concrete function for
detecting same actual types, seems an obvious solution now that
I've reread the typeid_of docs more closely.

I there any reason why something like the same_concrete check
couldn't be put in the:

  any
  ( const any< Concept2, Tag2 > & other
  , const binding< Concept > & binding
  );

body and an exception thrown if it doesn't pass?  It seems like
this would avoid any nasty surprises if the user gets a little
bit careless with the arguments to this CTOR.

If not, then at least the Requires clause in the doc for this
CTOR should have a strong warning about no diagnostic being
generated if this requirement is not met.

HTH

-regards,
Larry