The latest c++0x FCD defines the single argument constructor for reference_wrapper(T &) as non-explicit. The boost version is explicit. Was it done on purpose? Should it be changed to non-explicit? BTW, I think original standard drafts did have it as explicit since gcc 4.3.3 still defines it as explicit. But in the final draft (as in gcc 4.5) it's non-explicit. I know that boost::reference_wrapper is not the same as std::reference_wrapper, but still it would be nice to have some uniformity. Thanks, Andy.
At Wed, 21 Jul 2010 15:45:08 -0400, Andy Venikov wrote:
The latest c++0x FCD defines the single argument constructor for reference_wrapper(T &) as non-explicit.
The boost version is explicit. Was it done on purpose? Should it be changed to non-explicit?
BTW, I think original standard drafts did have it as explicit since gcc 4.3.3 still defines it as explicit. But in the final draft (as in gcc 4.5) it's non-explicit.
I know that boost::reference_wrapper is not the same as std::reference_wrapper, but still it would be nice to have some uniformity.
I guess it usually doesn't matter because you should use boost::ref(x) to create these objects anyway? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
At Wed, 21 Jul 2010 15:45:08 -0400, <snip>
I know that boost::reference_wrapper is not the same as std::reference_wrapper, but still it would be nice to have some uniformity.
I guess it usually doesn't matter because you should use boost::ref(x) to create these objects anyway?
True, but I did hit an issue with that recently. I had a generic function wrapper whose return type and an inner function to call was controlled by the user. Furthermore, it's not required that the return type of the inner function be the same as the return type of the wrapper as long as it's /*implicitly*/ convertible. So, when the user specified std::references_wrapper as the wrapper's return type (assuming that the inner function returns just a reference to a type), it worked. When switched to boost::reference_wrapper - it stopped working. For our needs we just dropped the /*implicit*/ requirement and the wrapper just forcibly converts the return of the inner function to it's own return type. But still... Thanks, Andy.
participants (2)
-
Andy Venikov -
David Abrahams