SkPDF: use sk_make_sp<T> when it makes sense.

src/pdf/SkPDFShader.h

Index: src/pdf/SkPDFShader.h
diff --git a/src/pdf/SkPDFShader.h b/src/pdf/SkPDFShader.h
index 3de17cdc509ca104c1e8f7ee949fd84b6f86eed5..dbf0b74b499cb822313aafec12e5e66be05bd042 100644
--- a/src/pdf/SkPDFShader.h
+++ b/src/pdf/SkPDFShader.h
@@ -51,17 +51,15 @@ public:
 };
 
 class SkPDFFunctionShader final : public SkPDFDict {
-    
-
 public:
     static SkPDFFunctionShader* Create(SkPDFCanon*,
                                        SkAutoTDelete<SkPDFShader::State>*);
+    SkPDFFunctionShader(SkPDFShader::State*);

[bungeman-skia, 2016/03/08 02:20:36]

eh, I don't think I'd make this public just because you want to be able to use
sk_make_sp on it.

[bungeman-skia, 2016/03/08 03:27:21]

I find this interesting and std::shared_pointer has a similar issue. It's
unfortunate, but the general consensus seems to be to just leave the constructor
private and use 'new' or to do something like

class Foo {
private:
    struct this_constructor_is_actually_private {};
public:
    Foo(this_constructor_is_actually_private&) {};
    sk_sp<Foo> Make() {
        return sk_make_sp<Foo>(this_constructor_is_actually_private());
    }
};

The idea being that now sk_make_sp can call the Foo constructor (it's public),
but only if it is called with an object of type
this_constructor_is_actually_private which only a member of Foo can create.
Honestly, it just seems cleaner to use 'new' since then the interface is
cluttered with public looking constructors which are actually uncallable by
clients.

[hal.canary, 2016/03/08 11:58:48]

Done.

     virtual ~SkPDFFunctionShader();
     bool equals(const SkPDFShader::State&) const;
 
 private:
     SkAutoTDelete<const SkPDFShader::State> fShaderState;
-    SkPDFFunctionShader(SkPDFShader::State*);
     typedef SkPDFDict INHERITED;
 };