Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   reference counting and constness (http://www.velocityreviews.com/forums/t955775-reference-counting-and-constness.html)

Marcel Müller 12-23-2012 10:21 PM

reference counting and constness
 
I experience some problems with ref counting when using const pointers.

It is quite straight forward to make the intrusive reference count
member mutable, since is not part of the logical object state. But any
smart pointer that handles reference counting must be able to invoke
operator delete. And operator delete requires a non const pointer. So a
smart pointers like intrusive_ptr<const MyType> cannot exist, isn't is?

How to deal with that?


Marcel

Marcel Müller 12-24-2012 11:34 AM

Re: reference counting and constness
 
On 24.12.12 00.08, Sam wrote:
>> I experience some problems with ref counting when using const pointers.
>>
>> It is quite straight forward to make the intrusive reference count
>> member mutable, since is not part of the logical object state. But any
>> smart pointer that handles reference counting must be able to invoke
>> operator delete. And operator delete requires a non const pointer. So
>> a smart pointers like intrusive_ptr<const MyType> cannot exist, isn't is?
>>
>> How to deal with that?

>
> I don't use Boost, but, by perusing the documentation, it looks to me
> like you need to define your own intrusive_ptr_release(), or specialize
> it, that takes a const ptr, and then does a const_cast<> on it.


I do not use boost either. It does not compile on my platform. But I use
my own smart pointers that have similar properties. But the main reason
why I spent no effort to make them compile is, that I need strong thread
safety and binary compatibility to const T*. Both is never provided by
boost.

But you say that a const_cast is safe in this case. Hopefully that's
true. I remember that there are different pointer aliasing rules for
const types. That might break compiler optimizations.

> Yuk. I think that the lack of proper const support both in Boost, and in
> C++11 is a glaring omission. Trying to force the templates to support
> them, by passing a const class as the template class, doesn't really
> work.


Sometimes it works well, but one can't cast the const away from the
const typename argument.

> And I also think that the various _ptr-s have other issues too.


They may have drawbacks but they saved my backside many, many times too.

> I think a better design is the one I used in LibCXX,
> http://www.libcxx.org/refobj.html, with a separate ptr and const_ptr,
> whose relationship is exactly equivalent to the relationship between
> iterator and const_iterator, and with ptr being a subclass of const_ptr,
> so that passing a ptr to a function that takes a const_ptr does not
> involve construction of a temporary object.


Hmm, that might be another approach. Unfortunately much to type.
And I am not sure whether inheritance from the const pointer type is the
right answer since the base must have a member of const T* which have to
be doubled in the derived class by T* or many, many const_casts are
necessary.

I will check for that. However, i still need to invoke operator delete
for a const pointer type.


Marcel

Marcel Müller 12-25-2012 10:29 PM

Re: reference counting and constness
 
On 24.12.12 13.24, Paavo Helde wrote:
>> And operator delete requires a non const pointer.

>
> What makes you think so? The following is perfectly valid C++:
>
> const A* a = new A();
> delete a;


Hmm, seems that one of my compilers has a different opinion. This made
me think so. But obviously you are right.


Marcel


James Kanze 12-28-2012 04:28 PM

Re: reference counting and constness
 
On Sunday, 23 December 2012 22:21:23 UTC, Marcel Müller wrote:
> I experience some problems with ref counting when using const pointers.


> And operator delete requires a non const pointer.


Is this something else they've changed in C++11? delete never
required a non-const pointer in the past.

--
James


All times are GMT. The time now is 03:42 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.