[type_erasure]bug:any(, binding<Concept>) can store wrong type
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? -regards, Larry
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. In Christ, Steven Watanabe
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,
And it's undefined behavior because it violates the Requires clause: the type stored in other must match the type expected by binding. from: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... The correspondence between the example code and the doc are: doc -> example code ----- --- ------------ other -> src_a binding -> dst_binding type stored in other -> src_concrete_t type expected by binding -> dst_concrete_t And obviously, src_concrete_t does not match dst_concrete_t, thus violating the Requires clause. Sorry, I should have read the Requires clause closer.
since there's no way to detect the problem at compile time. It's also not necessarily possible to add an assertion.
I guess one just has to be careful using this CTOR. Thanks. -Larry
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
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.
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.
Stephen, 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. TIA. -regards, Larry
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? [snip]
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.
OOPS. same_concrete just takes binding<Concept> args, which contain no data on which to visit. They just contain the function table :( Sorry for noise. -regards, Larry [snip]
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
participants (2)
-
Larry Evans -
Steven Watanabe