You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by achristianson <gi...@git.apache.org> on 2018/06/15 05:28:44 UTC
[GitHub] nifi-minifi-cpp pull request #359: MINIFICPP-515 Use emplace_back instead of...
GitHub user achristianson opened a pull request:
https://github.com/apache/nifi-minifi-cpp/pull/359
MINIFICPP-515 Use emplace_back instead of push_back
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [x] Does your PR title start with MINIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [x] Has your PR been rebased against the latest commit within the target branch (typically master)?
- [x] Is your initial contribution a single, squashed commit?
### For code changes:
- [x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?
### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFICPP-515
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi-minifi-cpp/pull/359.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #359
----
commit 0123dfa5579ca4d831fd608391ae54b5660a6d18
Author: Andrew I. Christianson <an...@...>
Date: 2018-06-15T05:27:46Z
MINIFICPP-515 Use emplace_back instead of push_back
----
---
[GitHub] nifi-minifi-cpp pull request #359: MINIFICPP-515 Use emplace_back instead of...
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/nifi-minifi-cpp/pull/359
---
[GitHub] nifi-minifi-cpp issue #359: MINIFICPP-515 Use emplace_back instead of push_b...
Posted by achristianson <gi...@git.apache.org>.
Github user achristianson commented on the issue:
https://github.com/apache/nifi-minifi-cpp/pull/359
@phrocker I read through the blog post.
The high level objective of this PR is to achieve the "copy free" state. The push_back( T&& value ) is what we want.
"in general push_back of already constructed objects with a move constructor should be fine"
It would copy, because the string is still valid after we add it (this would be "Case B" from the article):
"Case B is not affected (it still copies), and that's good, because we want to print s1 to cout below, so we want that data there."
"Case G" is the fit here, since the strings would still be valid. We need std::move to say that we're done with the string in this scope and it's OK for it to go into arbitrary post-move state.
I'll update to call push_back( T&& value ) which should be copy-free and is appropriate because we're not constructing an object.
---
[GitHub] nifi-minifi-cpp issue #359: MINIFICPP-515 Use emplace_back instead of push_b...
Posted by achristianson <gi...@git.apache.org>.
Github user achristianson commented on the issue:
https://github.com/apache/nifi-minifi-cpp/pull/359
Fixed.
---
[GitHub] nifi-minifi-cpp pull request #359: MINIFICPP-515 Use emplace_back instead of...
Posted by phrocker <gi...@git.apache.org>.
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/359#discussion_r195782604
--- Diff: libminifi/include/core/Property.h ---
@@ -65,15 +65,15 @@ class Property {
dependent_properties_(std::move(dependent_properties)),
exclusive_of_properties_(std::move(exclusive_of_properties)),
is_collection_(false) {
- values_.push_back(std::string(value.c_str()));
--- End diff --
I'm curious why this existed the way it did, but my guess is it's overriding the C++11 pointer copy to take ownership of that pointer. We have a named variable already and std::string has a move constructor so most of this is implicitly unnecessary [1], but I'm more concerned with the impetus for the ptr and std::string. That may have been someone ( could be me ) taking advantage of the ptr copy. I'll do al little research into that to validate, but in general push_back of already constructed objects with a move constructor should be fine; however, even in the case above I would have preferred emplacing the pointer than pushing since we're constructing an object to be appended, so I'll take a look at the string specs before approving to see if I can gather what the original intent was, here. My be a micro-optimization for pointer copies...but I think the move constructor does that for for SSOs, which many of these may be.
[1] http://ptspts.blogspot.com/2017/02/fast-vector-append.html
---
[GitHub] nifi-minifi-cpp issue #359: MINIFICPP-515 Use emplace_back instead of push_b...
Posted by phrocker <gi...@git.apache.org>.
Github user phrocker commented on the issue:
https://github.com/apache/nifi-minifi-cpp/pull/359
@achristianson I feel like there is something I'm missing because there had to have been a reason c_str() existed. On Friday I took another look and couldn't statically determine why that was one. So I'm inclined to merge this since there is no test or comment that alludes to why the newly constructed string was formulated.
---