Peter, shall I write a patch for the documentation for get_shared_count() and the new ctors? Or would you like to take care of that? Frank, is there any documentation for the improved enable_shared_from_this in trunk? It's hard to think about removing _owner with no documentation of what the expected behaviour is and what features/use-cases need to be supported. Regards, Daniel
On Wednesday 23 April 2008 17:20, Daniel Frey wrote:
Frank, is there any documentation for the improved enable_shared_from_this in trunk? It's hard to think about removing _owner with no documentation of what the expected behaviour is and what features/use-cases need to be supported.
No. The best thing to do is to go into libs/smart_ptr/test and type "bjam" and verify that nothing new is failing after you make your changes. If it looks okay you should be fine. The tests for the expected behavior of the new implementation are in the "esft_constructor_test" test. -- Frank
On Wed, 2008-04-23 at 23:20 +0200, Daniel Frey wrote:
Peter, shall I write a patch for the documentation for get_shared_count() and the new ctors? Or would you like to take care of that?
I prepared a patch for the documentation. While doing that, I noticed that the current ctor is a template ctor, which it should not be. Is: template<class Y> shared_ptr(detail::shared_count const & c, Y * p ); should be shared_ptr(detail::shared_count const & c, T * p ); likewise for the move-version. Also, for consistency purposes, one should also consider to add void reset( detail::shared_count const & c, T * p ); plus the move-version. OK to change from template to non-template ctor? OK to add the reset()-methods(s)? OK to commit the documentation (adapted on the answer to the above issues)? Regards, Daniel
On Thursday 24 April 2008 21:22, Daniel Frey wrote:
On Wed, 2008-04-23 at 23:20 +0200, Daniel Frey wrote:
Peter, shall I write a patch for the documentation for get_shared_count() and the new ctors? Or would you like to take care of that?
I prepared a patch for the documentation. While doing that, I noticed that the current ctor is a template ctor, which it should not be. Is:
What's the point of documenting an unspecified reference counter type? Following the interface specified by the docs, the only thing you can do with get_shared_count() is pass its return value directly to the constructor that takes a shared_count. That adds nothing over the aliasing constructor. You can't store the return value in a shared_count, because it's an unspecified type. -- Frank
On Thu, 2008-04-24 at 23:23 -0400, Frank Mori Hess wrote:
On Thursday 24 April 2008 21:22, Daniel Frey wrote:
On Wed, 2008-04-23 at 23:20 +0200, Daniel Frey wrote:
Peter, shall I write a patch for the documentation for get_shared_count() and the new ctors? Or would you like to take care of that?
I prepared a patch for the documentation. While doing that, I noticed that the current ctor is a template ctor, which it should not be. Is:
What's the point of documenting an unspecified reference counter type? Following the interface specified by the docs, the only thing you can do with get_shared_count() is pass its return value directly to the constructor that takes a shared_count. That adds nothing over the aliasing constructor. You can't store the return value in a shared_count, because it's an unspecified type.
Peter suggested to call it get_shared_count() instead of _internal_shared_count(), so I figured that this is going to be a documented public interface. I personally prefer it over the existing aliasing ctor, but when I suggested to remove the aliasing ctor, Peter said he is not interested in that. Even if the existing aliasing ctor remains, the new interface provides an alternative. And one that I would definitely prefer, I'd rather write x.reset( y.get_shared_count(), z ); than x.reset( y, z ); in my user code (likewise for ctors), since it is more explicit and IMHO communicates better what it does. Aliasing will probably not be used very often, but if it is, it's easier to spot and you can easily grep for it. Looking at the name, I realize that get_shared_count() might not be the best choice. We already have use_count() so get_shared_count() might be misleading. Maybe get_reference_counter()? Regards, Daniel
Replying to myself, again... hm... On Fri, 2008-04-25 at 09:09 +0200, Daniel Frey wrote:
On Thu, 2008-04-24 at 23:23 -0400, Frank Mori Hess wrote:
On Thursday 24 April 2008 21:22, Daniel Frey wrote:
I prepared a patch for the documentation. While doing that, I noticed that the current ctor is a template ctor, which it should not be. Is:
What's the point of documenting an unspecified reference counter type? Following the interface specified by the docs, the only thing you can do with get_shared_count() is pass its return value directly to the constructor that takes a shared_count. That adds nothing over the aliasing constructor. You can't store the return value in a shared_count, because it's an unspecified type.
[...]
Another point: Documenting this interface might not be the end. As a next step, one could consider to document the reference counter type (currently detail::shared_count) and its interface - at least a usable part of it. Which part might be useful and what benefits would it provide? What's a use case for it? I often use a shared_ptr<void> as a holder for mutex locks. Think of the mutex interface like this: namespace X { typedef shared_ptr<void> lock; struct mutex { mutex(); X::lock lock(); X::lock try_lock(); X::lock timed_lock( unsigned ms ); private: void unlock(); }; // v is accessed from different threads std::vector<foo> v; mutex m; void process_back() { lock l = m.lock(); if( v.empty() ) return; foo f = v.back(); // release the lock here l.reset(); // still use f here ... } } // namespace X The deleter of the returned X::lock calls mutext::unlock(). I also have another class X::rwmutex, which also uses X::lock, no need to define a second lock type. I often use l.reset() to free the lock before the scope it was defined in ends. I've often seen people using extra scopes for this, but this might conflict with other scopes and the lifetime of other variables. Other useful features are reassigning a lock and storing it (copy it somewhere). All of this come from shared_ptr<void> and the additional power is worth the overhead of the reference counter. What is never used (unlike the stored reference counter) is the void* itself that is stored inside the lock, so just using "typedef detail::shared_count lock;" should be enough and would reduce the overhead without loosing any functionality. Of course the interface of detail::shared_count should match shared_ptr's interface, i.e. .empty() should be turned into a bool conversion and there should be a .reset()-method. And some useful ctors. Probably not much more, but it all depends on what makes a good use case. Anyway, I'm not proposing this for now, just some thoughts on why it might be desirable to document the interface with unspecified-reference-counter-type. Regards, Daniel
Daniel Frey:
On Thu, 2008-04-24 at 23:23 -0400, Frank Mori Hess wrote:
On Thursday 24 April 2008 21:22, Daniel Frey wrote:
On Wed, 2008-04-23 at 23:20 +0200, Daniel Frey wrote:
Peter, shall I write a patch for the documentation for get_shared_count() and the new ctors? Or would you like to take care of that?
I prepared a patch for the documentation. While doing that, I noticed that the current ctor is a template ctor, which it should not be. Is:
What's the point of documenting an unspecified reference counter type? Following the interface specified by the docs, the only thing you can do with get_shared_count() is pass its return value directly to the constructor that takes a shared_count. That adds nothing over the aliasing constructor. You can't store the return value in a shared_count, because it's an unspecified type.
I agree with Frank that the "unspecified-type" documentation isn't very useful. The exact properties of the type are important (and would also affect the spec of ~shared_ptr and use_count). For example, shared_ptr<X> px( new X ); weak_ptr<X> wp( px ); auto v = px.get_shared_count(); px.reset(); // does ~X run here? wp.use_count(); // 0 or 1? With v being an "unspecified type", you can't tell. So... I'd rather not document the additional constructor and get_shared_count.
Peter suggested to call it get_shared_count() instead of _internal_shared_count(), so I figured that this is going to be a documented public interface.
I've never explained my naming convention, but I see you figured it out in the later posts; _internal_* represents a member that is logically private, but is kept public to avoid compiler bugs with template friends. It can go away at any time, even in a point release (in theory). We want get_shared_count to be supported and stable, but undocumented because it relies on detail::shared_count, which is in itself undocumented. (Actually the supported part implies a test, which we don't have, but still.)
participants (3)
-
Daniel Frey -
Frank Mori Hess -
Peter Dimov