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-14 10:37:29

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.

In another post about type_erasure:

  http://article.gmane.org/gmane.comp.lib.boost.devel/232966

you indicate implementing such a visitor pattern would be easy.
Providing a run-time check for the "wrong type store" problem would
be, IMO, a powerful incentive for implementing such a visitation
feature.

-regards,
Larry