Order the script badges in the location bar consistently

base/memory/scoped_ptr.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Scopers help you manage ownership of a pointer, helping you easily manage the
 // a pointer within a scope, and automatically destroying the pointer at the
 // end of a scope.  There are two main classes you will use, which correspond
 // to the operators new/delete and new[]/delete[].
 //
 // Example usage (scoped_ptr):
@@ skipping 475 matching lines @@
 template<class C, class FP> inline
 bool operator==(C* p, const scoped_ptr_malloc<C, FP>& b) {
   return p == b.get();
 }
 
 template<class C, class FP> inline
 bool operator!=(C* p, const scoped_ptr_malloc<C, FP>& b) {
   return p != b.get();
 }
 
+template <typename T>
+scoped_ptr<T> make_scoped_ptr() {

[willchan no longer on Chromium, 2012/06/15 23:15:01]

Can't we change this to take T*?

[Jeffrey Yasskin, 2012/06/15 23:17:38]

This could use a comment like

// Use this as:
//  make_scoped_ptr<MyClass>(constructor_arg1, constructor_arg2)
// For simplicity, we only forward 0-3 arguments, as const references. To
// construct with non-const references, create the scoped_ptr manually.


The interface matches make_shared<T>(...) from C++11 and the make_unique<T>(...)
that's been proposed for C++17, so I'm happy with it.

[willchan no longer on Chromium, 2012/06/18 03:16:53]

My initial inclination was to reject this, because this is not consistent with
make_linked_ptr() and make_scoped_refptr(). cs.chromium.org indicates that there
are on the order of 130~ instances of those two patterns in our code base.
make_linked_ptr() should not increase much more, but I suspect that
make_scoped_refptr() will continue to increase, primarily due to needing to do
so for passing function parameters to base::Bind().

In between beers, I've spent some background cycles pondering this. What's going
to be more common long-term? I see us likely switching to unique_ptr in the next
few years, at which point we could easily write our own make_unique<T> to match
the proposal for C++17. But I don't see us ever switching away from our uses of
make_scoped_refptr(), and I suspect they will be more commonly used than
make_scoped_ptr/make_unique.

There's another question...how much does consistency matter here? I guess my
inclination is that consistency with C++17 doesn't matter much, since that's so
far out, and it's not like many people know the standard. On the other hand,
most Chromium developers will expect make_*() to be consistent, so there are
real (albeit small, but sizable in aggregate) advantages to having these
functions be consistent in the Chromium codebase.

I don't really think this is worth discussing further, so I'm going to weakly
insist on being consistent with make_scoped_refptr() for now, unless others
strongly disagree here. Please chime in if you do!

[Jeffrey Yasskin, 2012/06/18 05:42:15]

Interestingly, make_scoped_refptr doesn't take ownership of any objects, unlike
the other make_* functions (it AddRef's, leaving a share of ownership with the
caller). For make_linked_ptr and the version of make_scoped_ptr that would take
a T*, passing the same pointer to two different calls would result in a
double-free. For make_scoped_refptr, it's perfectly fine, which makes it
semantically unreasonable to convert make_scoped_refptr to the construction form
that we see here.

To some extent I dislike the semantic inconsistency between make_shared_refptr
and the other make_* functions, but given that they're already
inconsistent-in-ownership but consistent-in-argument-types, I have no objection
to having make_scoped_ptr take a T*.

[not at google - send to devlin, 2012/06/18 17:50:27]

I think that... consistency with make_linked_ptr wins this one. I'll copy the
comment from there too.

Btw Will, why will make_linked_ptr go away?

[willchan no longer on Chromium, 2012/06/18 18:52:32]

I don't think it'll go away (did I say that? if so, I was wrong, sorry).
linked_ptr<T> is just not used much in general in our code, since it's not
threadsafe and also people are much more used to using RefCounted{ThreadSafe}. I
think its rate of new use is very low.

+  return scoped_ptr<T>(new T());
+}
+
+template <typename T, typename A1>
+scoped_ptr<T> make_scoped_ptr(const A1& a1) {
+  return scoped_ptr<T>(new T(a1));
+}
+
+template <typename T, typename A1, typename A2>
+scoped_ptr<T> make_scoped_ptr(const A1& a1, const A2& a2) {
+  return scoped_ptr<T>(new T(a1, a2));
+}
+
+template <typename T, typename A1, typename A2, typename A3>
+scoped_ptr<T> make_scoped_ptr(const A1& a1, const A2& a2, const A3& a3) {
+  return scoped_ptr<T>(new T(a1, a2, a3));
+}
+
 #endif  // BASE_MEMORY_SCOPED_PTR_H_