SK_ARRAY_COUNT shouldn't work on pointers.

SK_ARRAY_COUNT shouldn't work on pointers.

Simpler version of https://codereview.chromium.org/1123923002/

BUG=skia:3593
R=brucedawson@chromium.org,reed@google.com,tfarina@chromium.org

No public API changes.
TBR=reed@google.com

Committed: https://skia.googlesource.com/skia/+/fc00a7c5015ea534b0f28f8115bfb6253d275e1e

[mtklein, 2015-05-05 21:05:15]

The CQ bit was checked by mtklein@google.com to run a CQ dry run

[commit-bot: I haz the power, 2015-05-05 21:05:40]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1114283003/1

[mtklein_C, 2015-05-05 21:13:43]

mtklein@chromium.org changed reviewers:
+ brucedawson@chromium.org, tfarina@chromium.org
- mtklein@google.com

[mtklein_C, 2015-05-05 21:13:43]

Looks like we don't need the GCC workaround anymore?

[tfarina, 2015-05-05 21:22:57]

lgtm

[mtklein, 2015-05-05 21:40:12]

The CQ bit was checked by mtklein@google.com to run a CQ dry run

[commit-bot: I haz the power, 2015-05-05 21:40:34]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1114283003/20001

[commit-bot: I haz the power, 2015-05-05 21:46:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-05 21:46:28]

Dry run: This issue passed the CQ dry run.

[tfarina, 2015-05-06 00:08:15]

fyi, looks like we don't need the workaround in Chromium either.
https://codereview.chromium.org/1115993004/.

[brucedawson, 2015-05-06 00:20:00]

VC++ does have some known differences in its handling of templates. The VC++
team may address these in VC.Next (after VS 2015). So, don't let compiler
differences be a blocker -- they are expected.

[mtklein, 2015-05-06 12:55:35]

On 2015/05/06 00:20:00, brucedawson wrote:
> VC++ does have some known differences in its handling of templates. The VC++
> team may address these in VC.Next (after VS 2015). So, don't let compiler
> differences be a blocker -- they are expected.

Sorry, I didn't follow that.  Which compiler differences are you talking about? 
I don't see anything going wrong.

[brucedawson, 2015-05-06 17:17:49]

On 2015/05/06 12:55:35, mtklein wrote:
> On 2015/05/06 00:20:00, brucedawson wrote:
> > VC++ does have some known differences in its handling of templates. The VC++
> > team may address these in VC.Next (after VS 2015). So, don't let compiler
> > differences be a blocker -- they are expected.
> 
> Sorry, I didn't follow that.  Which compiler differences are you talking
about? 
> I don't see anything going wrong.

I wasn't suggesting that there was anything wrong. I was just commenting on some
mention of compiler template differences and the gcc/VC++ workaround.

That's nice that the workaround doesn't seem necessary anymore.

[mtklein, 2015-05-06 17:27:22]

On 2015/05/06 17:17:49, brucedawson wrote:
> On 2015/05/06 12:55:35, mtklein wrote:
> > On 2015/05/06 00:20:00, brucedawson wrote:
> > > VC++ does have some known differences in its handling of templates. The
VC++
> > > team may address these in VC.Next (after VS 2015). So, don't let compiler
> > > differences be a blocker -- they are expected.
> > 
> > Sorry, I didn't follow that.  Which compiler differences are you talking
> about? 
> > I don't see anything going wrong.
> 
> I wasn't suggesting that there was anything wrong. I was just commenting on
some
> mention of compiler template differences and the gcc/VC++ workaround.
> 
> That's nice that the workaround doesn't seem necessary anymore.

Sorry... I still don't understand.  What are we not letting be a blocker for
what?  Does this CL look correct to you?

[brucedawson, 2015-05-06 17:43:43]

I think the confusion arose because of the creation of a new CL. My comment was
only applicable to the old CL and I didn't notice the change.

lgtm.

[mtklein, 2015-05-06 17:45:34]

On 2015/05/06 17:43:43, brucedawson wrote:
> I think the confusion arose because of the creation of a new CL. My comment
was
> only applicable to the old CL and I didn't notice the change.
> 
> lgtm.

Gotcha. Thanks!

[mtklein, 2015-05-06 17:46:16]

mtklein@google.com changed reviewers:
+ reed@google.com

[mtklein, 2015-05-06 17:46:17]

+reed

This doesn't change public API, but I figured you might enjoy looking at what
references to arrays look like.

[brucedawson, 2015-05-06 18:04:11]

The "reference to array" technique can be useful elsewhere, BTW. CreateLinear,
for instance could be improved by this. Currently it has this prototype:

    static SkShader* CreateLinear(const SkPoint pts[2],
                                  const SkColor colors[], const SkScalar pos[],
int count,
                                  SkShader::TileMode mode,
                                  uint32_t flags, const SkMatrix* localMatrix);

It could be changed to be like this:

    Template<size_t count> SkShader* CreateLinear_safe(const SkPoint (&pts)[2],
                                  const SkColor (&colors)[count], const SkScalar
pos[],
                                  SkShader::TileMode mode,
                                  uint32_t flags, const SkMatrix* localMatrix)
{
    return CreateLinear(pts, colors, pos, count, mode, flags, localMatrix);
}

This *_safe function guarantees that the first parameter is an array with two
elements (currently any const SkPoint* will do) and it infers the size of the
colors array instead of requiring that it be passed in. The original
CreateLinear function can sometimes then be made private to make misuse
impossible (note that it continues to be the actual implementation).

Something to consider for future API design. I've had excellent luck with this
in the past.

[mtklein, 2015-05-07 17:47:20]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-05-07 17:47:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1114283003/20001

[commit-bot: I haz the power, 2015-05-07 17:58:49]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/fc00a7c5015ea534b0f28f8115bfb6253d275e1e