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