Boost logo

Boost Users :

From: Lars Hagström (lars_at_[hidden])
Date: 2007-10-31 14:03:49


Hi,

No, I don't really mind using the "long way". It is just that I was
surprised that the casts were commented out, since I kinda liked the way
that they mirrored shared_ptrs casting functions.
Using those casts are slightly more legible than doing it the long way.

But if you feel that they don't belong in the library, then I accept
your judgement.

Lars

Ion Gaztañaga wrote:
> Lars Hagström escribió:
>> Yes, but it has to be safer and more correct to use static_pointer_casts
>> instead of reinterpret_cast.
>> In my particular situation I am unfortunately not able to use templates,
>> so I do need to do "ugly" pointer stuff.
>> (I am porting an existing shared-memory solution to boost::interprocess).
>>
>> I've uncommented the static_pointer_cast et al functions from
>> offset_ptr.hpp, and they appear to do their work beautifully.
>>
>> Lars
>
> Sorry for the late reply. Originally I wrote static_pointer_cast & co.
> functions to mimic shared_ptr. I even used them as generic casting
> function for code where the pointer type is templated.
>
> However, those functions need an explicit template argument so ADL was
> not activated (say, like when you use an unqualified swap call). In the
> end I decided to comment them to prevent users using them (I should have
> erased them...).
>
> You can achieve the same using:
>
> offset_ptr(static_cast<MyType*>(my_offset_ptr.get()));
>
> without any performance hit, so I didn't consider them essential (ok,
> you have to type more ;-)). Is there any reason why you prefer
> static_pointer_cast instead of the code above? I have no problem to
> uncomment the code if you find it useful.
>
> Regards,
>
> Ion
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users




Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net