Fixed Windows compiler complaints

[robertphillips, 2012-07-10 13:14:51]

http://codereview.appspot.com/6392044/diff/1/include/core/SkData.h
File include/core/SkData.h (right):

http://codereview.appspot.com/6392044/diff/1/include/core/SkData.h#newcode24
include/core/SkData.h:24: 
Was generating error:

\include\core\skrefcnt.h(161): warning C4624: 'SkAutoTUnref<T>::BlockRef<B>' :
destructor could not be generated because a base class destructor is
inaccessible
          with
 [
      T=SkData
 ]
 and
 [
      B=SkData
 ]
 \trunk\tests\datareftest.cpp(36) : see reference to class template
instantiation 'SkAutoTUnref<T>::BlockRef<B>' being compiled
          with
 [
     T=SkData,
     B=SkData
 ]

[TomH, 2012-07-10 13:24:16]

Aside from the below, LGTM.

http://codereview.appspot.com/6392044/diff/1/include/core/SkData.h
File include/core/SkData.h (right):

http://codereview.appspot.com/6392044/diff/1/include/core/SkData.h#newcode24
include/core/SkData.h:24: 
On 2012/07/10 13:14:51, robertphillips wrote:
> Was generating error:
> 
> \include\core\skrefcnt.h(161): warning C4624: 'SkAutoTUnref<T>::BlockRef<B>' :

If we could replace the SkAutoTUnref<> with SkAutoDataUnref, we could declare
SkAutoDataUnref a friend and avoid making the destructor public?

(We do at least want to retain the change of declaring this destructor
virtual...)

[robertphillips, 2012-07-10 14:56:30]

Adding Ben & Mike for the SkData.h changes.

http://codereview.appspot.com/6392044/diff/1/include/core/SkData.h
File include/core/SkData.h (right):

http://codereview.appspot.com/6392044/diff/1/include/core/SkData.h#newcode24
include/core/SkData.h:24: 
As discussed w/ Mike and Ben I have added a friend call for SkAutoTUnref. I did
extend SkAutoDataUnref a bit so it could replace SkAutoTUnref in the
DataRefTest.

[reed1, 2012-07-10 15:04:03]

good comment on the friend.

http://codereview.appspot.com/6392044/diff/4002/include/core/SkData.h
File include/core/SkData.h (right):

http://codereview.appspot.com/6392044/diff/4002/include/core/SkData.h#newcode157
include/core/SkData.h:157: 
If we're going to open-the-lid with operator-> and SkData*(), can we remove the
previous APIs that were written for data(), byte() and size()?

[robertphillips, 2012-07-10 15:59:53]

I believe the data, size & bytes changes are safe due to the calls to copyToData
that precede them.

http://codereview.appspot.com/6392044/diff/4002/include/core/SkData.h
File include/core/SkData.h (right):

http://codereview.appspot.com/6392044/diff/4002/include/core/SkData.h#newcode157
include/core/SkData.h:157: 
On 2012/07/10 15:04:03, reed1 wrote:
> If we're going to open-the-lid with operator-> and SkData*(), can we remove
the
> previous APIs that were written for data(), byte() and size()?

Done.

[reed1, 2012-07-10 16:25:47]

Hmmm, I see that the old code for data/bytes/size handled a null object. Are the
existing callers ready to notice null themselves?

[reed1, 2012-07-10 16:27:01]

lgtm

[robertphillips, 2012-07-10 17:31:21]

committed as r4511