|
|
DescriptionImplement StringUTF8Adaptor::asStringPiece.
Permit //base/strings in WTF to support this.
Committed: https://crrev.com/cf7c1936b965a9771538b2e18a183115a431d8fc
Cr-Commit-Position: refs/heads/master@{#360727}
Patch Set 1 #Patch Set 2 : Add //base to wtf's public_deps. #
Messages
Total messages: 36 (11 generated)
Description was changed from ========== Implement StringUTF8Adaptor::asStringPiece. Also permit //base/strings in WTF to support conversion. ========== to ========== Implement StringUTF8Adaptor::asStringPiece. Permit //base/strings in WTF to support this. ==========
jbroman@chromium.org changed reviewers: + esprehn@chromium.org
This is how I'd like to resolve the "many copies" issue you mentioned in my other CL (combined with a change I've asked to make that place take base::StringPiece, because that function just constructs string pieces anyhow). usage looks like: String s = someBlinkFunction(); SomeChromiumFunction(WTF::StringUTF8Adaptor(s).asStringPiece()); This pattern is concise, has the right lifetime (due to temporaries surviving to the full statement), and efficient. In the (common) case where the string is ASCII (stored as an 8-bit string), the StringPiece points directly into the buffer with no copies. Otherwise StringUTF8Adaptor makes a single copy into a CString (to encode the data), and there are no further copies unless SomeChromiumFunction chooses to make them. StringPiece is also easy to convert to std::string if needed, or StringUTF8Adaptor could get an additional method for that (which would look almost identical to this one). In this case only a template is used (nothing requiring linkage to base), so I've only added the DEPS rule (for check-blink-deps) and BUILD.gn rule (for `gn check`), but not a corresponding gyp change. If this LGTY, I'll find a wtf/ owner, but I figured you'd want to have a look first.
esprehn@chromium.org changed reviewers: + jyasskin@chromium.org
This seems fine, jyasskin suggested we might use an operator to make this incantation shorter.
On 2015/11/17 at 21:09:14, esprehn wrote: > This seems fine, jyasskin suggested we might use an operator to make this incantation shorter. That was my initial inclination, but it seemed less controversial and/or magical to have a method than an implicit cast operator. I'm fine renaming asStringPiece to operator base::StringPiece if that's what makes people happy.
ping jyasskin?
lgtm, this is easy to change later so lets start here.
LGTM as-is or with an operator base::StringPiece. The implicit conversion is ok (and IMO preferable) because that's how base::StringPiece works in general: it already has implicit constructors from const char* and std::string.
landing as-is on the basis of esprehn's "lets start here"; deleting all calls to asStringPiece later is trivial if we want to go there
The CQ bit was checked by jbroman@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1458513002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1458513002/20001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, no build URL)
jbroman@chromium.org changed reviewers: + haraken@chromium.org
Whoops, forgot neither esprehn nor jyasskin is in wtf/OWNERS. +haraken for wtf/OWNERS
On 2015/11/19 22:21:08, jbroman wrote: > Whoops, forgot neither esprehn nor jyasskin is in wtf/OWNERS. > > +haraken for wtf/OWNERS LGTM
The CQ bit was checked by jbroman@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1458513002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1458513002/20001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, no build URL)
jbroman@chromium.org changed reviewers: + danakj@chromium.org
Apparently I need a base/ owner in order to use base::StringPiece? danakj, mind stamping this?
DEPS LGTM
The CQ bit was checked by jbroman@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1458513002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1458513002/20001
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/cf7c1936b965a9771538b2e18a183115a431d8fc Cr-Commit-Position: refs/heads/master@{#360727}
Message was sent while issue was closed.
yutak@chromium.org changed reviewers: + yutak@chromium.org
Message was sent while issue was closed.
Are we going to allow using base:: stuff outside wtf/, like from core/ or platform/? My understanding is "no", and if my understanding is correct, this change makes less sense.
Message was sent while issue was closed.
On 2015/12/09 10:37:23, Yuta Kitamura wrote: > Are we going to allow using base:: stuff outside wtf/, > like from core/ or platform/? My understanding is "no", > and if my understanding is correct, this change makes less > sense. Correct. The answer is no.
Message was sent while issue was closed.
On 2015/12/09 at 11:38:00, haraken wrote: > On 2015/12/09 10:37:23, Yuta Kitamura wrote: > > Are we going to allow using base:: stuff outside wtf/, > > like from core/ or platform/? My understanding is "no", > > and if my understanding is correct, this change makes less > > sense. > > Correct. The answer is no. It has to be allowed in platform/, because base types are part of the interface of cc etc., and those are now permitted in platform/. I agree that it makes sense to ban from core/.
Message was sent while issue was closed.
On 2015/12/09 14:25:53, jbroman wrote: > On 2015/12/09 at 11:38:00, haraken wrote: > > On 2015/12/09 10:37:23, Yuta Kitamura wrote: > > > Are we going to allow using base:: stuff outside wtf/, > > > like from core/ or platform/? My understanding is "no", > > > and if my understanding is correct, this change makes less > > > sense. > > > > Correct. The answer is no. > > It has to be allowed in platform/, because base types are part of the interface > of cc etc., and those are now permitted in platform/. I agree that it makes > sense to ban from core/. Sorry, I wrote the reply without reading the context well :/ You're right, base/ is allowed in wtf/ and platform/ and not allowed in other places.
Message was sent while issue was closed.
On 2015/12/09 15:00:35, haraken wrote: > On 2015/12/09 14:25:53, jbroman wrote: > > On 2015/12/09 at 11:38:00, haraken wrote: > > > On 2015/12/09 10:37:23, Yuta Kitamura wrote: > > > > Are we going to allow using base:: stuff outside wtf/, > > > > like from core/ or platform/? My understanding is "no", > > > > and if my understanding is correct, this change makes less > > > > sense. > > > > > > Correct. The answer is no. > > > > It has to be allowed in platform/, because base types are part of the > interface > > of cc etc., and those are now permitted in platform/. I agree that it makes > > sense to ban from core/. > > Sorry, I wrote the reply without reading the context well :/ You're right, base/ > is allowed in wtf/ and platform/ and not allowed in other places. OK, but let's get back to the original question: is it okay to have a function returning base::StringPiece in WTF? No, right?
Message was sent while issue was closed.
On 2015/12/10 06:11:44, Yuta Kitamura wrote: > On 2015/12/09 15:00:35, haraken wrote: > > On 2015/12/09 14:25:53, jbroman wrote: > > > On 2015/12/09 at 11:38:00, haraken wrote: > > > > On 2015/12/09 10:37:23, Yuta Kitamura wrote: > > > > > Are we going to allow using base:: stuff outside wtf/, > > > > > like from core/ or platform/? My understanding is "no", > > > > > and if my understanding is correct, this change makes less > > > > > sense. > > > > > > > > Correct. The answer is no. > > > > > > It has to be allowed in platform/, because base types are part of the > > interface > > > of cc etc., and those are now permitted in platform/. I agree that it makes > > > sense to ban from core/. > > > > Sorry, I wrote the reply without reading the context well :/ You're right, > base/ > > is allowed in wtf/ and platform/ and not allowed in other places. > > OK, but let's get back to the original question: is it okay to have > a function returning base::StringPiece in WTF? No, right? Ah, now I understand your question. That makes sense. jbroman@: Where is the StringUTF8Adaptor::asStringPiece going to be used?
Message was sent while issue was closed.
On 2015/12/10 at 06:18:39, haraken wrote: > On 2015/12/10 06:11:44, Yuta Kitamura wrote: > > On 2015/12/09 15:00:35, haraken wrote: > > > On 2015/12/09 14:25:53, jbroman wrote: > > > > On 2015/12/09 at 11:38:00, haraken wrote: > > > > > On 2015/12/09 10:37:23, Yuta Kitamura wrote: > > > > > > Are we going to allow using base:: stuff outside wtf/, > > > > > > like from core/ or platform/? My understanding is "no", > > > > > > and if my understanding is correct, this change makes less > > > > > > sense. > > > > > > > > > > Correct. The answer is no. > > > > > > > > It has to be allowed in platform/, because base types are part of the > > > interface > > > > of cc etc., and those are now permitted in platform/. I agree that it makes > > > > sense to ban from core/. > > > > > > Sorry, I wrote the reply without reading the context well :/ You're right, > > base/ > > > is allowed in wtf/ and platform/ and not allowed in other places. > > > > OK, but let's get back to the original question: is it okay to have > > a function returning base::StringPiece in WTF? No, right? > > Ah, now I understand your question. That makes sense. > > jbroman@: Where is the StringUTF8Adaptor::asStringPiece going to be used? I would only consider it legitimate (under the current rules) to call this in places that can otherwise access base/. I do think it's reasonable for WTF to provide code that allows conversion between WTF and base types, to be used by code that must deal with code (like platform/). Currently it's called in GraphicsLayer's implementation of cc::LayerClient::TakeDebugInfo (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...). |