Further reduction of feature_compiler.py generated code

extensions/common/features/complex_feature.cc

Index: extensions/common/features/complex_feature.cc
diff --git a/extensions/common/features/complex_feature.cc b/extensions/common/features/complex_feature.cc
index 5f041dbbc982786192cf3db7d81f36cc041dcbc5..a270e1c770e6b227bdb595ed39ea790c6bd81f8d 100644
--- a/extensions/common/features/complex_feature.cc
+++ b/extensions/common/features/complex_feature.cc
@@ -4,9 +4,11 @@
 
 #include "extensions/common/features/complex_feature.h"
 
+#include "base/stl_util.h"
+
 namespace extensions {
 
-ComplexFeature::ComplexFeature(std::unique_ptr<FeatureList> features) {
+ComplexFeature::ComplexFeature(FeatureList* features) {
   DCHECK_GT(features->size(), 0UL);
   features_.swap(*features);
   no_parent_ = features_[0]->no_parent();
@@ -28,6 +30,7 @@ ComplexFeature::ComplexFeature(std::unique_ptr<FeatureList> features) {
 }
 
 ComplexFeature::~ComplexFeature() {
+  STLDeleteElements(&features_);

[Devlin, 2016/07/29 18:50:14]

This makes me a bit sad.

Since we control the construction of the FeatureList and can avoid the
wrapping/unwrapping of all the unique_ptrs a bit more, is using raw ptrs still a
huge win over unique_ptrs here?

(I also notice that FeatureProvider's map still uses unique_ptrs - I'd think the
two containers would be similar.  So, conversely, if this *is* a big win, should
we do the same to the map?)

[scottmg, 2016/07/29 20:05:04]

Is something like this what you had in mind?

I'm not sure what you mean with FeatureProvider. The reason FeatureList was
changed was to avoid all the unique_ptr wrap/unwrap in the generated code. In
the actual implementation of ComplexFeature it's irrelevant.

 }
 
 Feature::Availability ComplexFeature::IsAvailableToManifest(