Callback support for unbound reference and array arguments.

base/callback_internal.h

 // Copyright (c) 2011 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.
 
 // This file contains utility functions and classes that help the
 // implementation, and management of the Callback objects.
 
 #ifndef BASE_CALLBACK_INTERNAL_H_
 #define BASE_CALLBACK_INTERNAL_H_
 #pragma once
@@ skipping 62 matching lines @@
 
   // Force the destructor to be instaniated inside this translation unit so
   // that our subclasses will not get inlined versions.  Avoids more template
   // bloat.
   ~CallbackBase();
 
   scoped_refptr<InvokerStorageBase> invoker_storage_;
   InvokeFuncStorage polymorphic_invoke_;
 };
 
+// This is a typetraits object that's used to take an argumen types, and

[akalin, 2011/03/24 00:40:19]

an argumen -> argument
storing, and forwarding -> storing and forwarding

[awong, 2011/03/24 01:37:17]

Done
Both you and Will apparently belong to the "no-to-serial-commas" camp. :P

Re-styled.

+// extract a suitable type for storing, and forwarding arguments.
+//
+// In particular, it strips off references, and converts arrays to
+// pointers for storage; and it avoids accidentally trying to create a
+// "reference of a reference" if the argument is a reference type.
+//
+// This array type becomes an issue for storage because we are passing bound
+// parameters by const reference. In this case, we end up passing an actual
+// array type in the initializer list which C++ does not allow.  This will
+// break passing of C-string literals.
+template <typename T>
+struct ParamTraits {
+  typedef const T& ForwardType;
+  typedef T StorageType;
+};
+
+// The Storage should almost be impossible to trigger unless someone manually
+// specifies type of the bind parameters.  However, in case they do,
+// this will guard against us accidentally storing a reference parameter.
+//
+// The ForwardType should only be used for unbound arguments.
+template <typename T>
+struct ParamTraits<T&> {
+  typedef T& ForwardType;
+  typedef T StorageType;
+};
+
+// Note that for array types, we implicitly add a const in the conversion. This
+// means that it is not possible to bind array arguments to functions that take
+// a non-const pointer. Trying to specialize the template based on a "const
+// T[n]" does not seem to match correctly, so we are stuck with this
+// restriction.
+template <typename T, size_t n>
+struct ParamTraits<T[n]> {
+  typedef const T* ForwardType;
+  typedef const T* StorageType;
+};
+
+template <typename T>

[akalin, 2011/03/24 00:40:19]

in this context, and in arguments, T[] means T*, right?

[awong, 2011/03/24 01:37:17]

Yes. As far as I know.  See the comment above for why we adorn a "const."

[akalin, 2011/03/24 01:49:18]

It might be less confusing to have the template type as "T*", and/or add a
comment reminding about the T*/T[] equivalence and when it applies.

[awong, 2011/03/24 01:58:56]

Unforutnately, during the actual pattern match for the type of the template, T[]
is still actually T[] and distinct from T*.  It's just that it effectively
"promotes" to T* when you use it as a parameter.

This code is used to make the template system do the equivalent promotion.

+struct ParamTraits<T[]> {
+  typedef const T* ForwardType;
+  typedef const T* StorageType;
+};
+
 }  // namespace internal
 }  // namespace base
 
 #endif  // BASE_CALLBACK_INTERNAL_H_