Reduce usage of operator LPCWSTR from CFX_WideString().

Reduce usage of operator LPCWSTR from CFX_WideString().

This involves adding some explicit c_str() calls. Doing so flagged
PDF_EncodeText() and FindOptionValue() as having suboptimal signatures, in
that we are often throwing away a perfectly fine length and recomputing it.

There are still some platform-specific code that needs the operator.

R=brucedawson@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/e6f11a7b95e26affba59a7057776a787056af8df

[Tom Sepez, 2015-04-24 01:19:05]

tsepez@chromium.org changed reviewers:
+ brucedawson@chromium.org, thestig@chromium.org

[Tom Sepez, 2015-04-24 01:19:05]

Lei, for review.  Bruce, I know you wanted this gone for a while.  Thanks.

[brucedawson, 2015-04-27 17:35:51]

lgtm

My only thought/question would be whether there are some places where
StringPiece could be used in order to avoid calls to c_str(). While calling
c_str() is a huge step over using a cast or implicit conversion, it is still
worse than either staying as a string object or (for leaf functions) converting
to StringPiece in order to retain the size information and allow safe implicit
conversion. Something to consider for future changes.

[Tom Sepez, 2015-04-27 18:21:35]

On 2015/04/27 17:35:51, brucedawson wrote:
> lgtm
> 
> My only thought/question would be whether there are some places where
> StringPiece could be used in order to avoid calls to c_str(). While calling
> c_str() is a huge step over using a cast or implicit conversion, it is still
> worse than either staying as a string object or (for leaf functions)
converting
> to StringPiece in order to retain the size information and allow safe implicit
> conversion. Something to consider for future changes.

As it turns out, there are a couple of places where the first thing the called
function does given the c_str() is to construct a CFX_xxxxString from it, which
does a malloc and memcpy, rather than just bumping a refcount on the existing
memory (and this needs a move constructor, yes).  Someday.

[Tom Sepez, 2015-04-27 18:22:25]

Committed patchset #3 (id:40001) manually as
15a62973b9b89c3e229cc0ab501c45967f91b325 (presubmit successful).

[Tom Sepez, 2015-04-27 18:32:43]

Re-opened due to revert.

[Tom Sepez, 2015-04-27 18:38:19]

On 2015/04/27 18:32:43, Tom Sepez wrote:
> Re-opened due to revert.

Closing without relanding.

[Tom Sepez, 2015-04-27 18:45:01]

And re-opening.  This is a perfectly fine issue# to use for landing.

I've put back the operator so that code will compile on other platforms,
pending further cleanup.  But this is still a step in the right direction.

[Tom Sepez, 2015-04-27 18:47:33]

Committed patchset #6 (id:100001) manually as
e6f11a7b95e26affba59a7057776a787056af8df (presubmit successful).