boost/pool/pool.hpp why reinterpret_cast instead of static_cast?

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

Philippe Vaucher wrote:
In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code:
static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); }
It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there?
Good question. I also think it should be static_cast<char*>. HTH, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

on Thu Mar 12 2009, Philippe Vaucher <philippe.vaucher-AT-gmail.com> wrote:
It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast.
No one knows? No one cares?
I care; it's one of my favorite axen to grind. Yes, avoid reinterpret_cast unless you really want implementation-defined behavior. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Okay, thank you for your answers. I'd like to hear the lib's author opinion about this. Unless he comes with a good reason for it (tho I can't see any), I think the cast should be changed. Should I create a ticket on the trac about it so it's not forgotten? Philippe

I'd like to hear the lib's author opinion about this. Unless he comes with a good reason for it (tho I can't see any), I think the cast should be changed.
Should I create a ticket on the trac about it so it's not forgotten?
So, should I create a ticket or not? Philippe

Philippe Vaucher wrote:
I'd like to hear the lib's author opinion about this. Unless he comes with a good reason for it (tho I can't see any), I think the cast should be changed.
Should I create a ticket on the trac about it so it's not forgotten?
So, should I create a ticket or not?
In general, filing issues in Trac increases the chances that the matter will be looked at. If you want such chances to be increased, file an issue. Be sure to set the right component, and maybe assign to Boost.Pool maintainer as per table in https://svn.boost.org/trac/boost/report/15 - Volodya

AMDG Vladimir Prus wrote:
In general, filing issues in Trac increases the chances that the matter will be looked at. If you want such chances to be increased, file an issue. Be sure to set the right component, and maybe assign to Boost.Pool maintainer as per table in https://svn.boost.org/trac/boost/report/15
If you set the component, the maintainer will be set automatically. In Christ, Steven Watanabe

In general, filing issues in Trac increases the chances that the matter will be looked at. If you want such chances to be increased, file an issue. Be sure to set the right component, and maybe assign to Boost.Pool maintainer as per table in https://svn.boost.org/trac/boost/report/15
Done, https://svn.boost.org/trac/boost/ticket/2941 Thanks, Philippe

It is my understanding that void* to T* convertions should be done
using
static_cast and not reinterpret_cast.
No one knows? No one cares?
I care; it's one of my favorite axen to grind. Yes, avoid reinterpret_cast unless you really want implementation-defined behavior.
Can you expand on that? Casting from void* to T* (or X* to Y*) is precisely when I'd use reinterpret_cast (and, indeed, it's not much use for anything else). Jim ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

Can you expand on that? Casting from void* to T* (or X* to Y*) is precisely when I'd use reinterpret_cast (and, indeed, it's not much use for anything else).
It looks like this is a common missunderstanding. Basically, when you know that the types involved will convert from one to the other, I think you should use static_cast. I found some pages more or less explaining my point better than I do, so I'll quote them : - http://msdn.microsoft.com/en-us/library/e0w9f63b(VS.80).aspx - *"The reinterpret_cast operator also allows any integral type to be converted into any pointer type and vice versa. Misuse of the reinterpret_cast operator can easily be unsafe. Unless the desired conversion is inherently low-level, you should use one of the other cast operators.*" - "*The result of a reinterpret_cast cannot safely be used for anything other than being cast back to its original type. Other uses are, at best, nonportable.*" - http://stackoverflow.com/questions/332030/when-should-staticcast-dynamiccast... - "*reinterpret_cast is the most dangerous cast, and should be used very sparingly. It turns one type directly into another - such as casting the value from one pointer to another, or storing a pointer in an int, or all sorts of other nasty things. Largely, the only guarantee you get with reinterpret_cast is that if you cast the result back to the original type, you will get the same value. Other than that, you're on your own. reinterpret_cast cannot do all sorts of conversions; in fact it is relatively limited. It should almost never be used (even interfacing with C code using void* can be done with static_cast).*" What makes you think void* to T* should be done with reinterpret_cast? I am interested to know. Thanks, Philippe

It's my understanding that static_casting the result of malloc is well defined behaviour, whereas using reinterpret_cast isn't.
Casting from void* to T* (or X* to Y*) is precisely when I'd use reinterpret_cast (and, indeed, it's not much use for anything else).
Because the result of a reinterpret_cast is implementation defined, it's only really useful when writing code that has implementation defined results by neccessity (endian handling code for example).
participants (7)
-
David Abrahams
-
James Talbut
-
Joseph Gauterin
-
Niels Dekker - mail address until 2010-10-10
-
Philippe Vaucher
-
Steven Watanabe
-
Vladimir Prus