[numeric_cast] request for boost::numeric_downcast
Hi Fernando, Amoung our utilities we have boost::polymorphic_cast boost::polymorphic_downcast The latter only performs a check in debug builds, and can then be used whenever the cast must succeed. boost::numeric_cast has no such alternative. Therefore I wuold like to see one. To keep in the naming convention from above, I think it could be reasonable to call this boost::numeric_downcast Furthermore, this should if possible be implemented in a seperate header (which is included in the main header) that can be compiled without exception-support. I think there are still platforms where they need this functionality, but don't want to sue exceptions. Any comments -Thorsten
Hi Thorsten,
Hi Fernando,
Amoung our utilities we have
boost::polymorphic_cast boost::polymorphic_downcast
The latter only performs a check in debug builds, and can then be used whenever the cast must succeed.
Oh... I wasn't aware of _downcast.
boost::numeric_cast has no such alternative. Therefore I wuold like to see one. To keep in the naming convention from above, I think it could be reasonable to call this
boost::numeric_downcast
Furthermore, this should if possible be implemented in a seperate header (which is included in the main header) that can be compiled without exception-support. I think there are still platforms where they need this functionality, but don't want to sue exceptions.
Indeed.. it all makes sense. I'll do it sometimes next week. Best Fernando
Thorsten Ottosen wrote:
Indeed.. it all makes sense.
I'll do it sometimes next week.
Thanks!
It does make me wonder if we should have a similar cast in Boost.Any:
boost::any_downcast
?
That approach seems like bloat. Couldn't polymorphic_cast and polymorphic_downcast be overloaded?
On Thu, 06 Nov 2008 15:24:11 +0100, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Thorsten Ottosen wrote:
It does make me wonder if we should have a similar cast in Boost.Any:
boost::any_downcast
?
That approach seems like bloat. Couldn't polymorphic_cast and polymorphic_downcast be overloaded?
How is that less bloat? And why would you call the cast any->concrete type a polymorphic cast? Sebastian
Sebastian Redl wrote:
That approach seems like bloat. Couldn't polymorphic_cast and polymorphic_downcast be overloaded?
How is that less bloat?
Having all of any_cast (dynamic_cast which always throws on error), any_unsafe_cast (static_cast), any_downcast (static_cast with debug checks) and finally any_test_cast (dynamic cast that can return null) doesn't seem like bloat to you? any_test_cast and any_unsafe_cast should be all you need to build all of the rest *outside* of the class. I would even like it better if 'any' directly overloaded dynamic_cast and static_cast in some way. And why would you call the cast any->concrete type
a polymorphic cast?
polymorphic_cast is really the same thing as a dynamic_cast, except it always throws even with dealing with pointers. polymorphic_downcast is really just a static_cast with some checking in debug mode. They should IMHO be implemented in terms of dynamic_pointer_cast and static_pointer_cast, since dynamic_cast and static_cast are not overloadable. Then any type that wants to implement safe and unsafe casts should overload *_pointer_cast instead of always reinventing names and funtions. And you get the fancy polymorphic casts for free, since they're written generically. The names were probably badly chosen, since there is nothing inherently polymorphic, but they're here now. I prefer having a single overloadable operator that always has the same meaning than a lot of class-specific utilities which do not cover everything, which is interface bloat to me.
Mathias Gaunard skrev:
Sebastian Redl wrote:
That approach seems like bloat. Couldn't polymorphic_cast and polymorphic_downcast be overloaded?
How is that less bloat?
Having all of any_cast (dynamic_cast which always throws on error), any_unsafe_cast (static_cast), any_downcast (static_cast with debug checks) and finally any_test_cast (dynamic cast that can return null) doesn't seem like bloat to you?
I only suggested to have two. For a majority of cases, static_cast can be replaced with XX_dowcast() that does a debug check. -Thorsten
on Thu Nov 06 2008, Fernando Cacciola <fernando.cacciola-AT-gmail.com> wrote:
Hi Thorsten,
Hi Fernando,
Amoung our utilities we have
boost::polymorphic_cast boost::polymorphic_downcast
The latter only performs a check in debug builds, and can then be used whenever the cast must succeed.
Oh... I wasn't aware of _downcast.
boost::numeric_cast has no such alternative. Therefore I wuold like to see one. To keep in the naming convention from above, I think it could be reasonable to call this
boost::numeric_downcast
Furthermore, this should if possible be implemented in a seperate header (which is included in the main header) that can be compiled without exception-support. I think there are still platforms where they need this functionality, but don't want to sue exceptions.
Indeed.. it all makes sense.
Not to me. In what sense is this proposed cast "down?" The point of boost::polymorphic_downcast is that it can be used for casting down the inheritance hierarchy, to more-derived classes. It cannot, however, be used for cross-casts as polymorphic_cast can. boost::polymorphic_downcast is meant to be used where you think you really know what derived type you've got, and you want an assertion to reinforce your reasoning with a runtime check. I suppose you can have a similar situation for numeric types (e.g. "I know this long int should fit in a short int"). How about boost::checked_cast, or boost::checked_narrowing_cast or boost::narrow_cast? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams skrev:
on Thu Nov 06 2008, Fernando Cacciola <fernando.cacciola-AT-gmail.com> wrote:
Hi Thorsten,
Hi Fernando,
Amoung our utilities we have
boost::polymorphic_cast boost::polymorphic_downcast
The latter only performs a check in debug builds, and can then be used whenever the cast must succeed.
Oh... I wasn't aware of _downcast.
boost::numeric_cast has no such alternative. Therefore I wuold like to see one. To keep in the naming convention from above, I think it could be reasonable to call this
boost::numeric_downcast
Furthermore, this should if possible be implemented in a seperate header (which is included in the main header) that can be compiled without exception-support. I think there are still platforms where they need this functionality, but don't want to sue exceptions.
Indeed.. it all makes sense.
Not to me. In what sense is this proposed cast "down?"
Well, as you say, its narrowing. The naming applied to polymorphic_cast and polymorphic_downcast is not perfect either, since both can be used to "casting down".
The point of boost::polymorphic_downcast is that it can be used for casting down the inheritance hierarchy, to more-derived classes. It cannot, however, be used for cross-casts as polymorphic_cast can.
boost::polymorphic_downcast is meant to be used where you think you really know what derived type you've got, and you want an assertion to reinforce your reasoning with a runtime check. I suppose you can have a similar situation for numeric types (e.g. "I know this long int should fit in a short int").
How about boost::checked_cast, or boost::checked_narrowing_cast or boost::narrow_cast?
I proposed numeric_downcast because I wanted "downcast" to mean an debug-checked version of _cast. There are quite a few casts in various boost libraries (any, smart pointer), and I think it would be nice if we could come up with a consistent naming convention this type of cast. How about boost::numeric_debug_cast boost::polymorphic_debug_cast boost::any_debug_cast ? -Thorsten
on Tue Nov 11 2008, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
Not to me. In what sense is this proposed cast "down?"
Well, as you say, its narrowing.
The naming applied to polymorphic_cast and polymorphic_downcast is not perfect either, since both can be used to "casting down".
That's like saying a knife is badly named because it can be used for "slicing carrots." -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams skrev:
on Tue Nov 11 2008, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
Not to me. In what sense is this proposed cast "down?" Well, as you say, its narrowing.
The naming applied to polymorphic_cast and polymorphic_downcast is not perfect either, since both can be used to "casting down".
That's like saying a knife is badly named because it can be used for "slicing carrots."
Do you disagree with my proposal that we should have some consistent way of naming a cast that does a debug check, but otherwise is unchecked? I suggested boost::numeric_debug_cast boost::polymorphic_debug_cast boost::any_debug_cast but perhaps boost::numeric_static_cast boost::polymorphic_static_cast boost::any_static_cast which reads nice, but the names are getting awfully long. -Thorsten
No, I agree. The casts should be called assert_dynamic_cast, etc. polymorphic_downcast is differ because it turns into a static_cast in release builds. Sent from my iPhone On Nov 14, 2008, at 9:02 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com
wrote:
David Abrahams skrev:
on Tue Nov 11 2008, Thorsten Ottosen <thorsten.ottosen-AT- dezide.com> wrote:
Not to me. In what sense is this proposed cast "down?" Well, as you say, its narrowing.
The naming applied to polymorphic_cast and polymorphic_downcast is not perfect either, since both can be used to "casting down". That's like saying a knife is badly named because it can be used for "slicing carrots."
Do you disagree with my proposal that we should have some consistent way of naming a cast that does a debug check, but otherwise is unchecked?
I suggested
boost::numeric_debug_cast boost::polymorphic_debug_cast boost::any_debug_cast
but perhaps
boost::numeric_static_cast boost::polymorphic_static_cast boost::any_static_cast
which reads nice, but the names are getting awfully long.
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 2:41 AM -0500 11/11/08, David Abrahams wrote:
boost::polymorphic_downcast is meant to be used where you think you really know what derived type you've got, and you want an assertion to reinforce your reasoning with a runtime check. I suppose you can have a similar situation for numeric types (e.g. "I know this long int should fit in a short int").
How about boost::checked_cast, or boost::checked_narrowing_cast or boost::narrow_cast?
Is this any different from boost::numeric_cast with an asserting rather than throwing overflow handler, plus boost/numeric/conversion paying attention to BOOST_NO_EXCEPTIONS, possibly by using boost::throw_exception?
Kim Barrett skrev:
At 2:41 AM -0500 11/11/08, David Abrahams wrote:
boost::polymorphic_downcast is meant to be used where you think you really know what derived type you've got, and you want an assertion to reinforce your reasoning with a runtime check. I suppose you can have a similar situation for numeric types (e.g. "I know this long int should fit in a short int").
How about boost::checked_cast, or boost::checked_narrowing_cast or boost::narrow_cast?
Is this any different from boost::numeric_cast with an asserting rather than throwing overflow handler, plus boost/numeric/conversion paying attention to BOOST_NO_EXCEPTIONS, possibly by using boost::throw_exception?
It depends. I can't remember how the overflow handler mechanism works, but we need to be able to have both types of casts in the same program. -Thorsten
At 2:57 PM +0100 11/14/08, Thorsten Ottosen wrote:
Kim Barrett skrev:
At 2:41 AM -0500 11/11/08, David Abrahams wrote:
boost::polymorphic_downcast is meant to be used where you think you really know what derived type you've got, and you want an assertion to reinforce your reasoning with a runtime check. I suppose you can have a similar situation for numeric types (e.g. "I know this long int should fit in a short int").
How about boost::checked_cast, or boost::checked_narrowing_cast or boost::narrow_cast?
Is this any different from boost::numeric_cast with an asserting rather than throwing overflow handler, plus boost/numeric/conversion paying attention to BOOST_NO_EXCEPTIONS, possibly by using boost::throw_exception?
It depends. I can't remember how the overflow handler mechanism works, but we need to be able to have both types of casts in the same program.
The asserting form of cast can pretty clearly be implemented using the overflow handler mechanism, so having both types of casts in the same program is supportable. My recollection is that the OP wanted something that works in a program compiled without exception support. I think that if the existing throwing default overflow handler were to use boost::throw_exception rather than directly using throw that the right thing should happen.
participants (6)
-
David Abrahams -
Fernando Cacciola -
Kim Barrett -
Mathias Gaunard -
Sebastian Redl -
Thorsten Ottosen