Explicitly implement copy ctor/assignment operator for IndexedDBKey

Explicitly implement copy ctor/assignment operator for IndexedDBKey

The implicit implementations by the compiler are inlined, and lead
to ~8k of unnecessary code.

R=bratell@opera.com
BUG=333205
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=244576

[jsbell, 2014-01-13 17:40:39]

bratell@ - want to take a peek? As noted in the bug, this shaved around 8k off
the lib, but I didn't make a stripped binary.

[jsbell, 2014-01-13 17:41:45]

(As an aside, we can safely collapse the date_ and number_ members as we do on
the Blink side but I'll do that as a separate CL.)

[Daniel Bratell, 2014-01-13 17:46:04]

On 2014/01/13 17:41:45, jsbell wrote:
> (As an aside, we can safely collapse the date_ and number_ members as we do on
> the Blink side but I'll do that as a separate CL.)

lgtm (though I'm not a code owner)

[dgrogan, 2014-01-13 17:46:21]

lgtm

[commit-bot: I haz the power, 2014-01-13 17:46:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jsbell@chromium.org/136853003/30001

[alecflett, 2014-01-13 18:03:54]

On 2014/01/13 17:40:39, jsbell wrote:
> bratell@ - want to take a peek? As noted in the bug, this shaved around 8k off
> the lib, but I didn't make a stripped binary.

is there a reason we need both the copy constructor AND the assignment operator?
Seems like we should be able to go with just one? possibly by simply
restructuring our code, but my understanding was that you only implement the
assignment operator for the same class if you can somehow implement it more
efficiently or if it has different semantics for your class than the copy
constructor?

[jsbell, 2014-01-13 18:12:29]

On 2014/01/13 18:03:54, alecflett wrote:
> On 2014/01/13 17:40:39, jsbell wrote:
> > bratell@ - want to take a peek? As noted in the bug, this shaved around 8k
off
> > the lib, but I didn't make a stripped binary.
> 
> is there a reason we need both the copy constructor AND the assignment
operator?
> Seems like we should be able to go with just one? possibly by simply
> restructuring our code, but my understanding was that you only implement the
> assignment operator for the same class if you can somehow implement it more
> efficiently or if it has different semantics for your class than the copy
> constructor?

I was following the Rule of Three [1] and just making the implementations
explicit, not touching the use. We probably could delete one of the two (well,
in C++03 make it private/unimplemented), touching more code.

[1] http://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming)

[jsbell, 2014-01-13 18:13:31]

And maybe we want to bubble this discussion into the bug, so we're consistent?

[commit-bot: I haz the power, 2014-01-13 18:17:50]

Retried try job too often on linux_rel for step(s) content_browsertests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2014-01-13 18:56:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jsbell@chromium.org/136853003/370001

[commit-bot: I haz the power, 2014-01-13 20:51:23]

Change committed as 244576