[smart_ptr] trunk version of enable_shared_from_this incompatible with TR1
TR1 states that the dtor of enable_shared_from_this is non-virtual, the trunk version violates this. Regards, Daniel
Daniel Frey:
TR1 states that the dtor of enable_shared_from_this is non-virtual, the trunk version violates this.
Yes. This is the least of our worries though. We need to decide on the direction we need to take. The upcoming C++ committee meeting is the last chance for a new feature to go into the working paper, and it may even be too late, depending on the LWG mood. I'm not sure yet what the best course of action is, but one reasonable course of action would be to propose sp_accept_owner (with the appropriate changes to enable_shared_from_this). An additional proposal may include the member to free function change, if we choose to pursue it. The current state of enable_shared_from_this is not in accordance with this plan. If we propose sp_accept_owner, I strongly prefer the trunk version of enable_shared_from_this to reflect the proposal, in a plain, unoptimized, "reference", doable in user space, form. Daniel, your optimization work takes us further away from this. Now is not the time to optimize; we need to be sure of the specification we're implementing, and even if we were, it pays off at the beginning to have a plain reference implementation that others can lift off as-is and include in their stdlibs. To get back to the subject, our current specification of sp_accept_owner requires the virtual destructor, a fact that had remained hidden (at least for me) because we don't have a reference implementation of the std changes we're (hypothetically) about to propose.
On Tue, Apr 29, 2008 at 12:45 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Daniel Frey:
TR1 states that the dtor of enable_shared_from_this is non-virtual, the trunk version violates this.
Yes. This is the least of our worries though.
So any class that I need to use enable_shared_from_this will be polymorphic? I don't find this very good. [snip] -- Felipe Magno de Almeida
On Tue, 2008-04-29 at 18:45 +0300, Peter Dimov wrote:
Daniel Frey:
TR1 states that the dtor of enable_shared_from_this is non-virtual, the trunk version violates this.
Yes. This is the least of our worries though.
We need to decide on the direction we need to take. The upcoming C++ committee meeting is the last chance for a new feature to go into the working paper, and it may even be too late, depending on the LWG mood.
Indeed.
I'm not sure yet what the best course of action is, but one reasonable course of action would be to propose sp_accept_owner (with the appropriate changes to enable_shared_from_this). An additional proposal may include the member to free function change, if we choose to pursue it.
Just to clarify: The proposed changes do or do not include the current extension to allow shared_from_this() to be called during the ctor?
The current state of enable_shared_from_this is not in accordance with this plan. If we propose sp_accept_owner, I strongly prefer the trunk version of enable_shared_from_this to reflect the proposal, in a plain, unoptimized, "reference", doable in user space, form. Daniel, your optimization work takes us further away from this. Now is not the time to optimize; we need to be sure of the specification we're implementing, and even if we were, it pays off at the beginning to have a plain reference implementation that others can lift off as-is and include in their stdlibs.
OK. Note that I only intended to help. I think the communication might not have been optimal so far, but your post definitely helps me to understand what the roadmap should be and what I should concentrate on. Except you think I can not be of any help... :-/
To get back to the subject, our current specification of sp_accept_owner requires the virtual destructor, a fact that had remained hidden (at least for me) because we don't have a reference implementation of the std changes we're (hypothetically) about to propose.
I think that if we adopt the approach of turning enable_shared_from_this into a non-template class and make shared_from_this a free function, there would no longer be any need for a virtual dtor. Since I don't know if shared_from_this-from-ctor should be in, I attached two version to show why the virtual dtor should not be required. I also tried to use only public interfaces (including sp_accept_owner). Both versions are untested, though. Or is there any other reason why sp_accept_owner requires a virtual dtor? Regards, Daniel
Daniel Frey:
Just to clarify: The proposed changes do or do not include the current extension to allow shared_from_this() to be called during the ctor?
My current line of thinking is that they should not, as even Frank is having second thoughts about it. But I haven't made up my mind yet. There's not much time left though.
Except you think I can not be of any help... :-/
Not really. I just think that you're currently contributing in the wrong area. We need to flesh out the specifications of the changes we are proposing. And with regards to the implementation, you could for example contrubute boost/make_shared.hpp (including documentation and tests), which is already accepted and (I hope) stable and really needs to be in 1.36.
I think that if we adopt the approach of turning enable_shared_from_this into a non-template class and make shared_from_this a free function, there would no longer be any need for a virtual dtor.
Yes, that's true. I view this as a separate proposal though since tying two more or less independent changes together increases the likelihood of both being rejected.
On Tue, 2008-04-29 at 20:03 +0300, Peter Dimov wrote:
Not really. I just think that you're currently contributing in the wrong area. We need to flesh out the specifications of the changes we are proposing. And with regards to the implementation, you could for example contrubute boost/make_shared.hpp (including documentation and tests), which is already accepted and (I hope) stable and really needs to be in 1.36.
I'm not sure that it's a good idea if I start something completely new at this point. I also have another idea I'm working on (Boost.Operators v2) and my time is not unlimited.
I think that if we adopt the approach of turning enable_shared_from_this into a non-template class and make shared_from_this a free function, there would no longer be any need for a virtual dtor.
Yes, that's true. I view this as a separate proposal though since tying two more or less independent changes together increases the likelihood of both being rejected.
OK, to help with the current enable_shared_from_this, may I suggest that I add some of the implementation variants to the sandbox <https://svn.boost.org/svn/boost/sandbox/libs/smart_ptr> just for further reference and try to turn the current implementation into a more reference-like version like the one from my previous post? Regards, Daniel
On Tue, 2008-04-29 at 20:03 +0300, Peter Dimov wrote:
My current line of thinking is that they should not, as even Frank is having second thoughts about it. But I haven't made up my mind yet. There's not much time left though.
Trying to implement enable_shared_from_this with only the public interface of shared_ptr, weak_ptr, etc. (and of course sp_accept_owner and sp_deleter_wrapper) turns out to be a good test for completeness IMHO. I tried to do this and found one thing that I cannot do with the current implementation of weak_ptr: I cannot test if it's empty. It lacks the conversion to bool, similar to shared_ptr. Or is there any way to do this I missed? I attached a patch (tested, passing all regression tests) to turn the current trunk version into a more reference-like implementation. It shows that conversion for bool of a weak_ptr is a desirable feature (see init_weak_once), since only now I understand what _owner was really meant for: It worked around the lack of weak_ptr conversion to bool by manually tracking it's internal state. In case conversion to bool seems to dangerous to you, I'd suggest to add at least an explicit method to test for px != 0 (.empty()?), to allow implementations to avoid tracking internal state manually. Regards, Daniel
On 4/29/08, Daniel Frey <d.frey@gmx.de> wrote:
I tried to do this and found one thing that I cannot do with the current implementation of weak_ptr: I cannot test if it's empty. It lacks the conversion to bool, similar to shared_ptr. Or is there any way to do this I missed? If you have an empty weak_ptr<foo> e, and another weak_ptr<foo> a, which you need to test for emptiness, you can use !(e<a) && !(a<e).
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, 2008-04-29 at 15:38 -0700, Emil Dotchevski wrote:
On 4/29/08, Daniel Frey <d.frey@gmx.de> wrote:
I tried to do this and found one thing that I cannot do with the current implementation of weak_ptr: I cannot test if it's empty. It lacks the conversion to bool, similar to shared_ptr. Or is there any way to do this I missed? If you have an empty weak_ptr<foo> e, and another weak_ptr<foo> a, which you need to test for emptiness, you can use !(e<a) && !(a<e).
Oh. Nice. Although it leaves us with an inefficient and quite ugly (IMHO) way to test it. But OK, I just asked if it's possible, not if it's pretty :) [It still looks stupid if I implement init_weak_once like this: void init_weak_once() const { weak_ptr<T> e; if( !( _weak_ptr < e ) && !( e < _weak_ptr ) ) { ... } } so maybe, Peter, .empty() would still make sense?] Regards, Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 29 April 2008 13:03 pm, Peter Dimov wrote:
We need to flesh out the specifications of the changes we are proposing.
One effect sp_accept_owner (and shared_from_this in constructors) have on the existing specifications is they put a big asterisk on the postconditions of some of the shared_ptr constructors. Really, all bets are off postcondition wise after sp_accept_owner has been called, unless restrictions are placed on what sp_accept_owner is allowed to do. Specifying that sp_accept_owner cannot modify its shared_ptr argument, as you suggested earlier, would allow some postconditions to be preserved, although not the ones involving "use_count() == 1". - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIF5hv5vihyNWuA4URAj4oAJ4wjSUPIUPJyGKiwKmpm8XkQinJlgCgiHC3 3M/KwUH+ymL/BAxUeO/Um+U= =AAaK -----END PGP SIGNATURE-----
Frank Mori Hess:
On Tuesday 29 April 2008 13:03 pm, Peter Dimov wrote:
We need to flesh out the specifications of the changes we are proposing.
One effect sp_accept_owner (and shared_from_this in constructors) have on the > existing specifications is they put a big asterisk on the postconditions of some of the shared_ptr constructors. Really, all bets are off postcondition wise after sp_accept_owner has been called, unless restrictions are placed on what sp_accept_owner is allowed to do. Specifying that sp_accept_owner cannot modify its shared_ptr argument, as you suggested earlier, would allow some postconditions to be preserved, although not the ones involving "use_count() == 1".
This is a very good point, probably even a showstopper for an eventual sp_accept_owner proposal. I note that creating a long-lived shared_ptr in the constructor breaks the postcondition as well. Annoying. In principle, a new esft may avoid this by: 1. Allowing only (expired) weak_ptr instances to be created in the constructor; 2. Bringing the weak_ptr instances back to life once a shared_ptr takes ownership. This however seems to require a relatively major surgery to sp_counted_base and friends; I'm not sure I'm comfortable with that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 30 April 2008 13:42 pm, Peter Dimov wrote:
In principle, a new esft may avoid this by:
1. Allowing only (expired) weak_ptr instances to be created in the constructor; 2. Bringing the weak_ptr instances back to life once a shared_ptr takes ownership.
This however seems to require a relatively major surgery to sp_counted_base and friends; I'm not sure I'm comfortable with that.
It sounds like you're heading in the direction of the "shared_from_that" idea I floated earlier: http://lists.boost.org/Archives/boost/2008/04/135372.php which would allow client code to distinguish between the cases of "shared_ptr not available yet" and "shared_ptr expired". - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIGOLC5vihyNWuA4URAlY7AJ992n4FL79aROGdGyZTsAA5Uv/ylACfbKmA OZDzTSDXTOAsRCRdqU8kQnY= =Xz99 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 30 April 2008 17:21, Frank Mori Hess wrote:
On Wednesday 30 April 2008 13:42 pm, Peter Dimov wrote:
In principle, a new esft may avoid this by:
1. Allowing only (expired) weak_ptr instances to be created in the constructor; 2. Bringing the weak_ptr instances back to life once a shared_ptr takes ownership.
This however seems to require a relatively major surgery to sp_counted_base and friends; I'm not sure I'm comfortable with that.
It sounds like you're heading in the direction of the "shared_from_that" idea I floated earlier:
http://lists.boost.org/Archives/boost/2008/04/135372.php
which would allow client code to distinguish between the cases of "shared_ptr not available yet" and "shared_ptr expired".
To be clear what I'm talking about, I've implemented a little proof of concept of "shared_from_that" and "enable_shared_from_that", and a little test program. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIGSRB5vihyNWuA4URAn3QAKDcxbahawcYUr5mAH6KRRPT29zaoQCfTi0e izDdZ98Cpi5PPr3D1nk0E8k= =HHfh -----END PGP SIGNATURE-----
Frank Mori Hess: ...
1. Allowing only (expired) weak_ptr instances to be created in the constructor; 2. Bringing the weak_ptr instances back to life once a shared_ptr takes ownership.
This however seems to require a relatively major surgery to sp_counted_base and friends; I'm not sure I'm comfortable with that.
It sounds like you're heading in the direction of the "shared_from_that" idea I floated earlier:
http://lists.boost.org/Archives/boost/2008/04/135372.php
which would allow client code to distinguish between the cases of "shared_ptr not available yet" and "shared_ptr expired".
To be clear what I'm talking about, I've implemented a little proof of concept of "shared_from_that" and "enable_shared_from_that", and a little test program.
What I had in mind is illustrated with the following: X * px = new X; // px->shared_from_this(); // throws bad_weak_ptr weak_ptr<X> wx = px->weak_from_this(); // OK assert( wx.use_count() == 0 ); // expired shared_ptr<X> sx( px ); assert( wx.use_count() == 1 ); // shares ownership with sx Also, not really related, but food for thought: the old behavior allows me to do something like the following pseudocode: void load( Archive & ar, shared_ptr<X> & px ) { X * p; ar >> p; try { px = p->shared_from_this(); } catch( bad_weak_ptr ) { px.reset( p ); } }
On Friday 02 May 2008 08:18, Peter Dimov wrote:
What I had in mind is illustrated with the following:
X * px = new X; // px->shared_from_this(); // throws bad_weak_ptr weak_ptr<X> wx = px->weak_from_this(); // OK assert( wx.use_count() == 0 ); // expired shared_ptr<X> sx( px ); assert( wx.use_count() == 1 ); // shares ownership with sx
It's not clear to me that this kind of behavior could be implemented for weak_ptr without changing its specification. Also, it doesn't allow for distinguishing between "object alive but no shared_ptr owner yet" and "shared_ptr expired or object destructed" cases. For the use case of tracking signal/slot connections, the signal would want to be able to distinguish between the two cases, temporarily blocking the connection in the first, and disconnecting it permanently in the second. What does seem to have the right semantics is for weak_from_this() to return something like a shared_ptr<weak_ptr<T> >. Every call would return a shared_ptr that points at the unique weak_ptr which will be assigned the object's owning shared_ptr. The "object alive but no owning shared_ptr" case would correspond to the weak_ptr being empty, and the "owning shared_ptr expired case" would correspond to the weak_ptr being expired. No changes to the specifications or implementations of shared_ptr/weak_ptr would be required. This is really all my shared_from_that class is (I'm starting to dislike my name choice btw). -- Frank
On Friday 02 May 2008 08:18, Peter Dimov wrote:
What I had in mind is illustrated with the following:
X * px = new X; // px->shared_from_this(); // throws bad_weak_ptr weak_ptr<X> wx = px->weak_from_this(); // OK assert( wx.use_count() == 0 ); // expired shared_ptr<X> sx( px ); assert( wx.use_count() == 1 ); // shares ownership with sx
It's not clear to me that this kind of behavior could be implemented for weak_ptr without changing its specification.
It's compatible with the specification of weak_ptr. use_count() returns the number of shared_ptr instances in the ownership group. Before the shared_ptr line, this number is zero, after it, it's one, exactly what is reported.
Also, it doesn't allow for distinguishing between "object alive but no shared_ptr owner yet" and "shared_ptr expired or object destructed" cases.
Yes, it doesn't.
For the use case of tracking signal/slot connections, the signal would want to be able to distinguish between the two cases, temporarily blocking the connection in the first, and disconnecting it permanently in the second.
In the first case, the signal should proceed to invoke the slots without the one that is in process of being constructed. I agree that it makes it hard to automatically disconnect the connection when its weak_ptr expires. In theory, you can avoid this by simply not disconnecting automatically.
What does seem to have the right semantics is for weak_from_this() to return something like a shared_ptr<weak_ptr<T> >. Every call would return a shared_ptr that points at the unique weak_ptr which will be assigned the object's owning shared_ptr.
It seems to me that now you have a data race on the weak_ptr target, which would require synchronization. There's a similar data race hidden in the above case as well, but it's not visible to the user (and seems less fequent, although I could be wrong).
On Saturday 03 May 2008 08:38, Peter Dimov wrote:
On Friday 02 May 2008 08:18, Peter Dimov wrote:
What I had in mind is illustrated with the following:
X * px = new X; // px->shared_from_this(); // throws bad_weak_ptr weak_ptr<X> wx = px->weak_from_this(); // OK assert( wx.use_count() == 0 ); // expired shared_ptr<X> sx( px ); assert( wx.use_count() == 1 ); // shares ownership with sx
It's not clear to me that this kind of behavior could be implemented for weak_ptr without changing its specification.
It's compatible with the specification of weak_ptr. use_count() returns the number of shared_ptr instances in the ownership group. Before the shared_ptr line, this number is zero, after it, it's one, exactly what is reported.
What I'm thinking is more along the lines of how a weak_ptr goes from "expired" to "good". Currently, that can only happen by assignment of a new shared_ptr. And assignment of one expired weak_ptr has no effect on any copies of the weak_ptr, they stay expired. It seems to me you would need to add a fourth weak_ptr state to the existing "empty", "good", and "expired" states, let's call it "reserved". A "reserved" weak_ptr would have a use_count of zero, but any copies of it would be related to it in the sense that when a reserved weak_ptr is assigned a shared_ptr, it and all its copies all move from the "reserved" state to the "good" state together. And some kind of token would need to be added for use as a parameter to a new constructor that creates a "reserved" weak_ptr.
Also, it doesn't allow for distinguishing between "object alive but no shared_ptr owner yet" and "shared_ptr expired or object destructed" cases.
Yes, it doesn't.
If the idea of a "reserved" weak_ptr was added, it could be made to throw a different exception than bad_weak_ptr (perhaps derived from bad_weak_ptr) when an attempt is made to construct a shared_ptr from it.
For the use case of tracking signal/slot connections, the signal would want to be able to distinguish between the two cases, temporarily blocking the connection in the first, and disconnecting it permanently in the second.
In the first case, the signal should proceed to invoke the slots without the one that is in process of being constructed. I agree that it makes it hard to automatically disconnect the connection when its weak_ptr expires. In theory, you can avoid this by simply not disconnecting automatically.
Yes, but in the case of a long-lived signal with many short-lived connections, it would effectively create a resource leak when relying on automatic connection management.
What does seem to have the right semantics is for weak_from_this() to return something like a shared_ptr<weak_ptr<T> >. Every call would return a shared_ptr that points at the unique weak_ptr which will be assigned the object's owning shared_ptr.
It seems to me that now you have a data race on the weak_ptr target, which would require synchronization.
Yes, the shared_ptr<weak_ptr<T> > would have to be wrapped in a class with a mutex to make it thread-safe, or weak_ptr itself would have to provide stronger thread-safety guarantees. Also, it should really have a const in there: shared_ptr<const weak_ptr<T> >. -- Frank
Frank Mori Hess:
What I'm thinking is more along the lines of how a weak_ptr goes from "expired" to "good". Currently, that can only happen by assignment of a new shared_ptr. And assignment of one expired weak_ptr has no effect on any copies of the weak_ptr, they stay expired.
This is correct as far as it goes. But in the case I showed, no assignment happens to any of the weak_ptr instances. Consider how weak_ptrs go from use_count of 1 to use_count of 0 without any assignment. This is the same event in reverse. It can't normally occur now, of course. Remember that use_count() does not report the state of a particular instance, it reports program-wide state (the number of shared_ptr instances sharing ownership with *this). It can and will go up and down without any changes to *this.
Yes, but in the case of a long-lived signal with many short-lived connections, it would effectively create a resource leak when relying on automatic connection management.
Well, there would be no automatic connection management, so obviously relying on it would be a bad idea. :-) One would have to use scoped connections or manual disconnects in the destructor, as usual.
On Saturday 03 May 2008 13:52, Peter Dimov wrote:
Frank Mori Hess:
What I'm thinking is more along the lines of how a weak_ptr goes from "expired" to "good". Currently, that can only happen by assignment of a new shared_ptr. And assignment of one expired weak_ptr has no effect on any copies of the weak_ptr, they stay expired.
This is correct as far as it goes. But in the case I showed, no assignment happens to any of the weak_ptr instances. Consider how weak_ptrs go from use_count of 1 to use_count of 0 without any assignment. This is the same event in reverse. It can't normally occur now, of course.
Remember that use_count() does not report the state of a particular instance, it reports program-wide state (the number of shared_ptr instances sharing ownership with *this). It can and will go up and down without any changes to *this.
Well, okay the changes I described for a "reserved" weak_ptr could be left as unspecified implementation details, except for the throwing of an alternate exception for a reserved weak_ptr. Although, it could just store the "expired or reserved?" information in the bad_weak_ptr object. As far as I know, there is nothing much specified about what the interface of the bad_weak_ptr class has to look like. -- Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 03 May 2008 13:52 pm, Peter Dimov wrote:
Frank Mori Hess:
What I'm thinking is more along the lines of how a weak_ptr goes from "expired" to "good". Currently, that can only happen by assignment of a new shared_ptr. And assignment of one expired weak_ptr has no effect on any copies of the weak_ptr, they stay expired.
This is correct as far as it goes. But in the case I showed, no assignment happens to any of the weak_ptr instances. Consider how weak_ptrs go from use_count of 1 to use_count of 0 without any assignment. This is the same event in reverse. It can't normally occur now, of course.
Remember that use_count() does not report the state of a particular instance, it reports program-wide state (the number of shared_ptr instances sharing ownership with *this). It can and will go up and down without any changes to *this.
Yes, but in the case of a long-lived signal with many short-lived connections, it would effectively create a resource leak when relying on automatic connection management.
Well, there would be no automatic connection management, so obviously relying on it would be a bad idea. :-) One would have to use scoped connections or manual disconnects in the destructor, as usual.
To respond to a month-old post (sorry): disconnecting in the destructor is not thread-safe, since the slot may still be running concurrently when disconnect() returns. Automatic connection management has to be used, so the signal can lock its weak_ptr and prevent the tracked object from destructing while the slot is still being run. I still like the idea of something like template<typename T> future<weak_ptr<T> > future_weak_from_this(T *this) which would be safely useable in the constructor, and allow distinguishing "no owner yet" from "expired". It doesn't belong in the smart_ptr lib due to the dependency on a future lib, but maybe it could be slipped into boost somewhere when futures are added. By the way, did you ever decide if you wanted to add a raw pointer argument to sp_accept_owner() due to the dynamic_cast issue? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIPwFq5vihyNWuA4URAiVaAKDY6OdVuVwUCCKvkf63EtJicRGj7wCg5kl5 ygKvKIKG2lpfg8Y5VH3Fxo4= =dZfa -----END PGP SIGNATURE-----
On Saturday 03 May 2008 08:38, Peter Dimov wrote:
On Friday 02 May 2008 08:18, Peter Dimov wrote: For the use case of tracking signal/slot connections, the signal would want to be able to distinguish between the two cases, temporarily blocking the connection in the first, and disconnecting it permanently in the second.
In the first case, the signal should proceed to invoke the slots without the one that is in process of being constructed.
To be clear, that's what "blocking a connection" means in the context of the signals documentation. I wasn't talking about blocking like blocking a process or thread. -- Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 30 April 2008 13:42 pm, Peter Dimov wrote:
In principle, a new esft may avoid this by:
1. Allowing only (expired) weak_ptr instances to be created in the constructor; 2. Bringing the weak_ptr instances back to life once a shared_ptr takes ownership.
This however seems to require a relatively major surgery to sp_counted_base and friends; I'm not sure I'm comfortable with that.
How uncomfortable are you with it? I might try to implement the "reserved" weak_ptr idea, if I can add some way to distinguish between "expired and reserved" and plain old "expired". lock() could return an empty shared_ptr with a non-null stored pointer for a "reserved" weak_ptr? That's probably too evil. A "bool reserved() const" member function? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHxuZ5vihyNWuA4URArg+AJ0ajvwRvM1NAbqK6n75Jzyr2RcWbwCbBY4r NJBgshMzI4HI8LscV7qUuFk= =CBph -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 29 April 2008 13:03 pm, Peter Dimov wrote:
And with regards to the implementation, you could for example contrubute boost/make_shared.hpp (including documentation and tests), which is already accepted and (I hope) stable and really needs to be in 1.36.
Your reference implementation make_shared.cpp available from the web doesn't have any copyright or license information listed in it. Is it allright to use as the basis for the boost implementation and tests? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIF8PZ5vihyNWuA4URAsn6AKDLHAkyiTLTIUsuGIywUJ260aQe7ACgyq/R z+UkV0rJjUI99Oseej5QYwE= =ML76 -----END PGP SIGNATURE-----
Frank Mori Hess:
On Tuesday 29 April 2008 13:03 pm, Peter Dimov wrote:
And with regards to the implementation, you could for example contrubute boost/make_shared.hpp (including documentation and tests), which is already accepted and (I hope) stable and really needs to be in 1.36.
Your reference implementation make_shared.cpp available from the web doesn't > have any copyright or license information listed in it. Is it allright to use as the basis for the boost implementation and tests?
Yes, the lack of the BSL at the top is an oversight on my part. I hereby place it under the Boost Software License 1.0.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 29 April 2008 21:12 pm, Peter Dimov wrote:
Yes, the lack of the BSL at the top is an oversight on my part. I hereby place it under the Boost Software License 1.0.
How about n2351 "Improving shared_ptr for C++0x, Revision 2"? Is it legal to copy parts of it for the boost make_shared documentation? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIGeFZ5vihyNWuA4URAnypAKDLX4aYk2woLiTXBw7Ln/+c2HyXpQCdGa/v TCeqJZk/1yCBZvSdPPHIVkA= =NLx0 -----END PGP SIGNATURE-----
Frank Mori Hess:
On Tuesday 29 April 2008 21:12 pm, Peter Dimov wrote:
Yes, the lack of the BSL at the top is an oversight on my part. I hereby place it under the Boost Software License 1.0.
How about n2351 "Improving shared_ptr for C++0x, Revision 2"? Is it legal to copy parts of it for the boost make_shared documentation?
Yes.
participants (6)
-
Daniel Frey -
Emil Dotchevski -
Felipe Magno de Almeida -
Frank Mori Hess -
Frank Mori Hess -
Peter Dimov