szaszm commented on a change in pull request #900:
URL: https://github.com/apache/nifi-minifi-cpp/pull/900#discussion_r486988154
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Understood. I'd go for 3.
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Note: I didn't really review this PR, just briefly looked at the diff
and shared my thoughts about it. Me generally preferring 3. is because it's
normally not nullable and doesn't enforce any lifetime semantics of the object,
which is normally the ideal when we only care about the object. When storing as
a data member, I prefer 5. or 4, because they are mutable and sometimes one
needs nullable members to be able to implement move semantics.
With that said, I can accept any other way, in any case, especially given
good reasoning (e.g. the proliferation of shared_ptr throughout the codebase).
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Note: I didn't really review this PR, just briefly looked at the diff
and shared my thoughts about it. Me generally preferring 3. is because it's
normally not nullable and doesn't enforce any lifetime semantics of the object,
which is normally the ideal when we only care about the object. When storing as
a data member, I prefer 5. or 4, because they are mutable and sometimes one
needs nullable members to be able to implement move semantics.
With that said, I can accept any other way (i.e. I'm okay with all), in any
case, especially given good reasoning (e.g. the proliferation of shared_ptr
throughout the codebase).
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Understood. I'd go for 3.
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Note: I didn't really review this PR, just briefly looked at the diff
and shared my thoughts about it. Me generally preferring 3. is because it's
normally not nullable and doesn't enforce any lifetime semantics of the object,
which is normally the ideal when we only care about the object. When storing as
a data member, I prefer 5. or 4, because they are mutable and sometimes one
needs nullable members to be able to implement move semantics.
With that said, I can accept any other way, in any case, especially given
good reasoning (e.g. the proliferation of shared_ptr throughout the codebase).
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Note: I didn't really review this PR, just briefly looked at the diff
and shared my thoughts about it. Me generally preferring 3. is because it's
normally not nullable and doesn't enforce any lifetime semantics of the object,
which is normally the ideal when we only care about the object. When storing as
a data member, I prefer 5. or 4, because they are mutable and sometimes one
needs nullable members to be able to implement move semantics.
With that said, I can accept any other way (i.e. I'm okay with all), in any
case, especially given good reasoning (e.g. the proliferation of shared_ptr
throughout the codebase).
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Understood. I'd go for 3.
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Note: I didn't really review this PR, just briefly looked at the diff
and shared my thoughts about it. Me generally preferring 3. is because it's
normally not nullable and doesn't enforce any lifetime semantics of the object,
which is normally the ideal when we only care about the object. When storing as
a data member, I prefer 5. or 4, because they are mutable and sometimes one
needs nullable members to be able to implement move semantics.
With that said, I can accept any other way, in any case, especially given
good reasoning (e.g. the proliferation of shared_ptr throughout the codebase).
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
Note: I didn't really review this PR, just briefly looked at the diff
and shared my thoughts about it. Me generally preferring 3. is because it's
normally not nullable and doesn't enforce any lifetime semantics of the object,
which is normally the ideal when we only care about the object. When storing as
a data member, I prefer 5. or 4, because they are mutable and sometimes one
needs nullable members to be able to implement move semantics.
With that said, I can accept any other way (i.e. I'm okay with all), in any
case, especially given good reasoning (e.g. the proliferation of shared_ptr
throughout the codebase).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
