I like leakPtr.
Personally, releasePtr() is so close to release() (which is safe) that I
could easily overlook it in a code review and not realize that it hands off
a raw pointer with a ref count on it.
dave
On Tue, Jun 29, 2010 at 10:40 AM, Darin Adler da...@apple.com wrote:
On Jun 28,
I like leakPtr.
Personally, releasePtr() is so close to release() (which is safe) that I
could easily overlook it in a code review and not realize that it hands off a
raw pointer with a ref count on it.
dave
+1
Anders once argued against the name leakPtr, Well, then you might as well
Hi folks.
I’d like to use our smart pointers more consistently to decrease the chances of
memory leaks or other similar problems.
My proposal is that we have a rule that all calls to new are immediately
followed by putting the object into a smart pointer. The main types of smart
pointer that
6) Add validator rules that make invocation of the new operator legal
only inside adoptRef and adoptPtr function calls.
That is probably going to be a problem for Qt code on the WebKit API
side. If we disable this rule for WebKitTools and WebKit I think we
should be OK
Kenneth
On Mon, Jun 28, 2010 at 1:43 PM, Kenneth Christiansen
kenneth.christian...@openbossa.org wrote:
6) Add validator rules that make invocation of the new operator legal
only inside adoptRef and adoptPtr function calls.
That is probably going to be a problem for Qt code on the WebKit API
Sounds great. Let me know how I can help.
Do we need an exception for statics that we intend to leak at
shutdown? Maybe leakPtr(new Foo)?
Adam
On Mon, Jun 28, 2010 at 1:39 PM, Darin Adler da...@apple.com wrote:
Hi folks.
I’d like to use our smart pointers more consistently to decrease the
Is the plan also to banish the std::auto_ptr? It seems pointless and
confusing to allow both the OwnPtr and the auto_ptr.
antti (who wants PwnPtr too)
On Mon, Jun 28, 2010 at 11:39 PM, Darin Adler da...@apple.com wrote:
Hi folks.
I’d like to use our smart pointers more consistently to
On Jun 28, 2010, at 2:14 PM, Adam Barth wrote:
Do we need an exception for statics that we intend to leak at shutdown? Maybe
leakPtr(new Foo)?
Maybe.
My first thought for such things is that I’d prefer to write them as:
adoptPtr(new Foo).releasePtr()
At first that may look strange, but
On Jun 28, 2010, at 2:55 PM, Antti Koivisto wrote:
Is the plan also to banish the std::auto_ptr? It seems pointless and
confusing to allow both the OwnPtr and the auto_ptr.
Yes, that would be my preference.
PassOwnPtr is intended as a replacement for std::auto_ptr. Before PassOwnPtr
I like this idea. Addressing some of the side comments:
- Yes, we should get rid of auto_ptr.
- I can imagine a leakPtr function being more self-documenting than
adoptPtr(...).releasePtr() when it appears in code, but on the other hand the
greater convenience may lead to using it carelessly.
10 matches
Mail list logo
