| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Review requested:
|
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
Small suggestion; otherwise lgtm.
Sorry, something went wrong.
| void SetArgs(Environment* env, Local<Value> argv[10], const ada::result& url) { | ||
| void SetArgs(Environment* env, | ||
| Local<Value> (*argv)[10], | ||
| const ada::result& url) { |
There was a problem hiding this comment.
Ideally this parameter should be an const ada::url&. It doesn't make sense to pass an ada::result in when we always expect it to be filled with the "valid" value.
In fact the call sites should probably change from this:
ada::result out = ada::parse(input.ToStringView());
CHECK(out);
out->set_protocol(…);to
ada::result out = ada::parse(input.ToStringView());
CHECK(out);
const ada::url& url = out.value();
url.set_protocol(…);
Sorry, something went wrong.
There was a problem hiding this comment.
out.value() returns a copy. The current implementation looks unsafe, but CHECK(out) ensures that it is not. I tried to avoid returning a copy. @lemire wrote about this on Ada's discussion board: ada-url/ada#200
Sorry, something went wrong.
There was a problem hiding this comment.
I think you misunderstood ada-url/ada#200. out.value() (and equivalently *out) does not return a copy by itself. It returns a reference, so if you put it into a const ada::url& then no copies are made.
On the other hand, ada::url url = *out, which would make a copy. That's not what I'm suggesting here.
Alternatively, you can also do
ada::result out = ada::parse(input.ToStringView());
CHECK(out);
ada::url url = std::move(*out);which is written under the "performance tip". It would also avoid a copy.
Sorry, something went wrong.
There was a problem hiding this comment.
It is likely that the current code is safe and efficient. I think we are discussing 'coding style' which is subjective.
I don't personally find the url->... annoying.
I am slightly triggered by the (*argv)[..] however. :-)
What about using a reference to an array instead?
Local<Value> (&argv)[10]
(The ampersand would be dropped from the calling site.)
Sorry, something went wrong.
There was a problem hiding this comment.
It's a style guide thing: pointers for things that are mutated, const references otherwise.
With mutable references it's sometimes ambiguous to a reader if code operates on the original or on a copy. With pointers, no such ambiguity exists.
Sorry, something went wrong.
There was a problem hiding this comment.
The current fix LGTM but it feels like a C-style fix. Since this is a C++ file, we could also leverage the power of C++:
Since the problem described in #46541 (comment) is about array arguments decaying to pointers, why don't we use std::array here instead? The doc states:
Unlike a C-style array, it doesn't decay to T* automatically.
Doing that should also address https://github.com/nodejs/node/pull/47001/files#r1130218455:
I am slightly triggered by the (*argv)[..] however. :-)
Sorry, something went wrong.
|
@RaisinTen per convention, the std::array would have to be passed by pointer, so IMO it doesn't provide much benefit. More elaboration in #47001 (comment). |
Sorry, something went wrong.
|
Or you could just return a std::vector<Local<Value> and do Call(...., argv.size(), argv.data()) later ;) I doubt there is any meaningful performance difference between the two, and no one needs to actually count the number of arguments in the code that way, and you can get rid of the undef fillers in the caller. |
Sorry, something went wrong.
|
You could also just return a std::array? That would make intention clear better than an out parameters does, and would still avoid the dynamic memory allocation from std::vector (in fact, I'd expect it to compile to pretty much the same code as the current state of this PR). |
Sorry, something went wrong.
|
Since there isn't any request for changes on this pull request, I'll add a commit-queue label. |
Sorry, something went wrong.
Implements a review suggestion from 72e971e. Refs: nodejs#47001 (comment)
PR-URL: #47001 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com>
Implements a review suggestion from 72e971e. Refs: #47001 (comment) PR-URL: #47035 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: #47001 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com>
Implements a review suggestion from 72e971e. Refs: #47001 (comment) PR-URL: #47035 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: nodejs#47001 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com>
Implements a review suggestion from 72e971e. Refs: nodejs#47001 (comment) PR-URL: nodejs#47035 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Implements a review suggestion from 72e971e. Refs: #47001 (comment) PR-URL: #47035 Backport-PR-URL: #48345 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
| Back | FazBrowse Home | New Git URL |
I am following up on @tniessen's pull request and @bnoordhuis's comments. @TimothyGu, thanks for the mention & reminder
Reference: #46541 (comment)