explicit shared_ptr(weak_ptr<Y> const & r);
Hi Peter, Just a thought: perhaps this constructor: explicit shared_ptr(weak_ptr<Y> const & r); should be private, and the only way to create a shared_ptr from a weak_ptr is: shared_ptr<T> val = weak->lock(); This way, the shared_ptr public constructors will never throw. Users will not make mistakes like this: shared_ptr<T> val = weak; I'm saying this, because I just made this mistake a few hours ago... After a while, the shared_ptr<> constructor started to throw at me ;) Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo wrote:
Hi Peter,
Just a thought: perhaps this constructor: explicit shared_ptr(weak_ptr<Y> const & r);
should be private, and the only way to create a shared_ptr from a weak_ptr is:
shared_ptr<T> val = weak->lock();
This way, the shared_ptr public constructors will never throw. Users will not make mistakes like this:
shared_ptr<T> val = weak;
This shouldn't compile on a reasonably compliant compiler, because the constructor is explicit.
Peter Dimov wrote:
John Torjo wrote:
Hi Peter,
Just a thought: perhaps this constructor: explicit shared_ptr(weak_ptr<Y> const & r);
should be private, and the only way to create a shared_ptr from a weak_ptr is:
shared_ptr<T> val = weak->lock();
This way, the shared_ptr public constructors will never throw. Users will not make mistakes like this:
shared_ptr<T> val = weak;
This shouldn't compile on a reasonably compliant compiler, because the constructor is explicit.
True, sorry, I meant this: shared_ptr<T> val(weak); The point still remains. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
John Torjo wrote:
Peter Dimov wrote:
John Torjo wrote:
Hi Peter,
Just a thought: perhaps this constructor: explicit shared_ptr(weak_ptr<Y> const & r);
should be private, and the only way to create a shared_ptr from a weak_ptr is:
shared_ptr<T> val = weak->lock();
This way, the shared_ptr public constructors will never throw. Users will not make mistakes like this:
shared_ptr<T> val = weak;
This shouldn't compile on a reasonably compliant compiler, because the constructor is explicit.
True, sorry, I meant this:
shared_ptr<T> val(weak);
The point still remains.
I'm not sure that it does. The canonical way to work with a weak_ptr is if( shared_ptr<T> p = weak.lock() ) { // do things with *p } You can't accidentally omit the lock(), and shared_ptr<T> p( weak ) is invalid in an if statement. shared_ptr<T> val( weak ); does exactly what it is intended to do.
You can't accidentally omit the lock(), and shared_ptr<T> p( weak ) is invalid in an if statement.
shared_ptr<T> val( weak ); does exactly what it is intended to do.
It does what it is documented to do. But I really fail to see any code that would actually prefer this: shared_ptr<T> val( weak ); over this: shared_ptr<T> val = weak.lock(); Thus, people might use the former synax by mistake. At least, I did it ;) Basically, actually my mistake was more subtle: struct wnd { shared_ptr<...> p; // bug here: it should have actually been shared_ptr<...> wnd( weak_ptr<...> p) : p(p) {} }; struct weak_wnd { weak_ptr<...> p; shared_ptr<...> to_wnd() const { return p.lock(); } }; weak_wnd a; // a.to_wnd(): // a shared pointer gets constructed, which is automatically converted // to a weak_ptr, which then is converted to a shared_ptr wnd b = a.to_wnd(); Had that constuctor not been public, this would have generated a compile-time error. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
participants (2)
-
John Torjo -
Peter Dimov