Subject: Re: [boost] [type_erasure]bug:any(, binding<Concept>) can store wrong type
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-08-16 10:41:22
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
> 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.
> In another post about type_erasure:
> 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
I'm now trying to figure out how to implement such a visitor pattern
in type_erasure myself. Do you have any advice on how I should start?
Right now, I'm using the debugger to step through how the previously
attached program implements that any_cast. I'm hoping that will give
me some ideas of how to do it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk