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