Boost logo

Boost :

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:
>> 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:
>>> 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:
> 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.
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:

  ( 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at