You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2017/10/03 23:26:44 UTC
[VOTE] C++ standardize on return values only
Voting on the conversation around C++ return values vs. out parameters.
This vote is to adopt the standard of return values over the use of out
parameters. On functions that must return more than one value to use the
C++11 std::tuple type for future compatibility with C++17.
For example:
std::tuple<int, std::string> foo::getAAndB() {...}
And call it with:
int a;
std::string b;
std::tie(a, b) = foo.getAAndB();
Alternatively the tuple can be called like:
auto r = foo.getAAndB();
auto a = std::get<0>(r);
auto b = std::get<1>(r);
In C++17:
auto [a, b] = foo.getAAndB();
Rather than:
int foo::getAAndB(std::string& b) {...}
Called like
std::string b;
auto a = foo.getAAndB(b);
-Jake
Re: [VOTE] C++ standardize on return values only
Posted by Michael William Dodge <md...@pivotal.io>.
+1 for the tuple
> On 4 Oct, 2017, at 08:01, Ernest Burghardt <eb...@pivotal.io> wrote:
>
> +1 Tuple
>
> On Wed, Oct 4, 2017 at 7:58 AM, David Kimura <dk...@pivotal.io> wrote:
>
>> +1
>>
>> On Tue, Oct 3, 2017 at 5:45 PM, Hitesh Khamesra
>> <hiteshk25@yahoo.com.invalid
>>> wrote:
>>
>>> Tuple option.
>>>
>>> Sent from Yahoo Mail on Android
>>>
>>> On Tue, Oct 3, 2017 at 4:27 PM, Jacob Barrett<jb...@pivotal.io>
>>> wrote: Voting on the conversation around C++ return values vs. out
>>> parameters.
>>> This vote is to adopt the standard of return values over the use of out
>>> parameters. On functions that must return more than one value to use the
>>> C++11 std::tuple type for future compatibility with C++17.
>>>
>>> For example:
>>>
>>> std::tuple<int, std::string> foo::getAAndB() {...}
>>>
>>> And call it with:
>>>
>>> int a;
>>> std::string b;
>>> std::tie(a, b) = foo.getAAndB();
>>>
>>> Alternatively the tuple can be called like:
>>>
>>> auto r = foo.getAAndB();
>>> auto a = std::get<0>(r);
>>> auto b = std::get<1>(r);
>>>
>>> In C++17:
>>>
>>> auto [a, b] = foo.getAAndB();
>>>
>>>
>>>
>>> Rather than:
>>>
>>> int foo::getAAndB(std::string& b) {...}
>>>
>>> Called like
>>>
>>> std::string b;
>>> auto a = foo.getAAndB(b);
>>>
>>> -Jake
>>>
>>>
>>
Re: [VOTE] C++ standardize on return values only
Posted by Ernest Burghardt <eb...@pivotal.io>.
+1 Tuple
On Wed, Oct 4, 2017 at 7:58 AM, David Kimura <dk...@pivotal.io> wrote:
> +1
>
> On Tue, Oct 3, 2017 at 5:45 PM, Hitesh Khamesra
> <hiteshk25@yahoo.com.invalid
> > wrote:
>
> > Tuple option.
> >
> > Sent from Yahoo Mail on Android
> >
> > On Tue, Oct 3, 2017 at 4:27 PM, Jacob Barrett<jb...@pivotal.io>
> > wrote: Voting on the conversation around C++ return values vs. out
> > parameters.
> > This vote is to adopt the standard of return values over the use of out
> > parameters. On functions that must return more than one value to use the
> > C++11 std::tuple type for future compatibility with C++17.
> >
> > For example:
> >
> > std::tuple<int, std::string> foo::getAAndB() {...}
> >
> > And call it with:
> >
> > int a;
> > std::string b;
> > std::tie(a, b) = foo.getAAndB();
> >
> > Alternatively the tuple can be called like:
> >
> > auto r = foo.getAAndB();
> > auto a = std::get<0>(r);
> > auto b = std::get<1>(r);
> >
> > In C++17:
> >
> > auto [a, b] = foo.getAAndB();
> >
> >
> >
> > Rather than:
> >
> > int foo::getAAndB(std::string& b) {...}
> >
> > Called like
> >
> > std::string b;
> > auto a = foo.getAAndB(b);
> >
> > -Jake
> >
> >
>
Re: [VOTE] C++ standardize on return values only
Posted by David Kimura <dk...@pivotal.io>.
+1
On Tue, Oct 3, 2017 at 5:45 PM, Hitesh Khamesra <hiteshk25@yahoo.com.invalid
> wrote:
> Tuple option.
>
> Sent from Yahoo Mail on Android
>
> On Tue, Oct 3, 2017 at 4:27 PM, Jacob Barrett<jb...@pivotal.io>
> wrote: Voting on the conversation around C++ return values vs. out
> parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
>
> For example:
>
> std::tuple<int, std::string> foo::getAAndB() {...}
>
> And call it with:
>
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
>
> Alternatively the tuple can be called like:
>
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
>
> In C++17:
>
> auto [a, b] = foo.getAAndB();
>
>
>
> Rather than:
>
> int foo::getAAndB(std::string& b) {...}
>
> Called like
>
> std::string b;
> auto a = foo.getAAndB(b);
>
> -Jake
>
>
Re: [VOTE] C++ standardize on return values only
Posted by Hitesh Khamesra <hi...@yahoo.com.INVALID>.
Tuple option.
Sent from Yahoo Mail on Android
On Tue, Oct 3, 2017 at 4:27 PM, Jacob Barrett<jb...@pivotal.io> wrote: Voting on the conversation around C++ return values vs. out parameters.
This vote is to adopt the standard of return values over the use of out
parameters. On functions that must return more than one value to use the
C++11 std::tuple type for future compatibility with C++17.
For example:
std::tuple<int, std::string> foo::getAAndB() {...}
And call it with:
int a;
std::string b;
std::tie(a, b) = foo.getAAndB();
Alternatively the tuple can be called like:
auto r = foo.getAAndB();
auto a = std::get<0>(r);
auto b = std::get<1>(r);
In C++17:
auto [a, b] = foo.getAAndB();
Rather than:
int foo::getAAndB(std::string& b) {...}
Called like
std::string b;
auto a = foo.getAAndB(b);
-Jake
Re: [VOTE] C++ standardize on return values only
Posted by Jacob Barrett <jb...@pivotal.io>.
Stick with the out variable on this one and any others like this that are consistent with the Java API. The primary goal was to remove the very odd void readInt(int& int) calls.
> On Oct 18, 2017, at 3:08 PM, Mark Hanson <mh...@pivotal.io> wrote:
>
> Sorry about that last email... to begin again....
>
> Hello All,
>
> So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion.
>
> As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g.
> inline void readBytesOnly(int8_t* buffer, uint32_t len) {
> if (len > 0) {
> checkBufferSize(len);
> std::memcpy(buffer, m_buf, len);
> m_buf += len;
> }
> }
>
> That throws a kink into the whole no out variables discussion. It is addressable, for this question, we want to know how the community would like to move forward, would it be best just to leave an API like this alone and call it exceptional? Would it be best for us to allocate a std::unique_ptr, or less desirably a share_ptr? I could see leaving it as is, because the java API does this and it give greater discretion to the caller, however, I think a fine case can be made for using a unique_ptr as well.
>
> From a higher level for this API only, should we get rid of this API and have it dealt with through its more standard types? This is kind of an end run for accessing generic data, if you look at it right…
>
> What do you think?
>
> Thanks,
> Mark
>
>
> On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>> wrote:
> Hello All,
>
> So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion.
>
> As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g.
>
>
> On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett <jbarrett@pivotal.io <ma...@pivotal.io>> wrote:
> Voting on the conversation around C++ return values vs. out parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
>
> For example:
>
> std::tuple<int, std::string> foo::getAAndB() {...}
>
> And call it with:
>
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
>
> Alternatively the tuple can be called like:
>
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
>
> In C++17:
>
> auto [a, b] = foo.getAAndB();
>
>
>
> Rather than:
>
> int foo::getAAndB(std::string& b) {...}
>
> Called like
>
> std::string b;
> auto a = foo.getAAndB(b);
>
> -Jake
>
>
Re: [VOTE] C++ standardize on return values only
Posted by Michael William Dodge <md...@pivotal.io>.
I have seen the uint8_t *, uint32_t tuple mostly with C-style system level calls (e.g., reading from a resource). Perhaps these could be allowed to remain as part of lowering impedance with a legacy API.
Sarge
> On 18 Oct, 2017, at 15:08, Mark Hanson <mh...@pivotal.io> wrote:
>
> Sorry about that last email... to begin again....
>
> Hello All,
>
> So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion.
>
> As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g.
> inline void readBytesOnly(int8_t* buffer, uint32_t len) {
> if (len > 0) {
> checkBufferSize(len);
> std::memcpy(buffer, m_buf, len);
> m_buf += len;
> }
> }
>
> That throws a kink into the whole no out variables discussion. It is addressable, for this question, we want to know how the community would like to move forward, would it be best just to leave an API like this alone and call it exceptional? Would it be best for us to allocate a std::unique_ptr, or less desirably a share_ptr? I could see leaving it as is, because the java API does this and it give greater discretion to the caller, however, I think a fine case can be made for using a unique_ptr as well.
>
> From a higher level for this API only, should we get rid of this API and have it dealt with through its more standard types? This is kind of an end run for accessing generic data, if you look at it right…
>
> What do you think?
>
> Thanks,
> Mark
>
>
> On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>> wrote:
> Hello All,
>
> So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion.
>
> As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g.
>
>
> On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett <jbarrett@pivotal.io <ma...@pivotal.io>> wrote:
> Voting on the conversation around C++ return values vs. out parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
>
> For example:
>
> std::tuple<int, std::string> foo::getAAndB() {...}
>
> And call it with:
>
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
>
> Alternatively the tuple can be called like:
>
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
>
> In C++17:
>
> auto [a, b] = foo.getAAndB();
>
>
>
> Rather than:
>
> int foo::getAAndB(std::string& b) {...}
>
> Called like
>
> std::string b;
> auto a = foo.getAAndB(b);
>
> -Jake
>
>
Re: [VOTE] C++ standardize on return values only
Posted by Mark Hanson <mh...@pivotal.io>.
Sorry about that last email... to begin again....
Hello All,
So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion.
As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g.
inline void readBytesOnly(int8_t* buffer, uint32_t len) {
if (len > 0) {
checkBufferSize(len);
std::memcpy(buffer, m_buf, len);
m_buf += len;
}
}
That throws a kink into the whole no out variables discussion. It is addressable, for this question, we want to know how the community would like to move forward, would it be best just to leave an API like this alone and call it exceptional? Would it be best for us to allocate a std::unique_ptr, or less desirably a share_ptr? I could see leaving it as is, because the java API does this and it give greater discretion to the caller, however, I think a fine case can be made for using a unique_ptr as well.
From a higher level for this API only, should we get rid of this API and have it dealt with through its more standard types? This is kind of an end run for accessing generic data, if you look at it right…
What do you think?
Thanks,
Mark
On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>> wrote:
Hello All,
So in doing some work on this subject, we have come across a case that David and I believed was worth raising for discussion.
As one might expect, at some point, someone is going to pass in a buffer and a length into a function and expect data put into that buffer, e.g.
On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett <jbarrett@pivotal.io <ma...@pivotal.io>> wrote:
Voting on the conversation around C++ return values vs. out parameters.
This vote is to adopt the standard of return values over the use of out
parameters. On functions that must return more than one value to use the
C++11 std::tuple type for future compatibility with C++17.
For example:
std::tuple<int, std::string> foo::getAAndB() {...}
And call it with:
int a;
std::string b;
std::tie(a, b) = foo.getAAndB();
Alternatively the tuple can be called like:
auto r = foo.getAAndB();
auto a = std::get<0>(r);
auto b = std::get<1>(r);
In C++17:
auto [a, b] = foo.getAAndB();
Rather than:
int foo::getAAndB(std::string& b) {...}
Called like
std::string b;
auto a = foo.getAAndB(b);
-Jake
Re: [VOTE] C++ standardize on return values only
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Oct 18, 2017, at 2:49 PM, Mark Hanson <mh...@pivotal.io> wrote:
> So in doing some work on this subject, we have come across a case that
> David and I believed was worth raising for discussion.
>
> As one might expect, at some point, someone is going to pass in a buffer
> and a length into a function and expect data put into that buffer, e.g.
And did you have a position to discuss?
Passing a buffer to get filled is an ok exception.
-Jake
Re: [VOTE] C++ standardize on return values only
Posted by Mark Hanson <mh...@pivotal.io>.
Hello All,
So in doing some work on this subject, we have come across a case that
David and I believed was worth raising for discussion.
As one might expect, at some point, someone is going to pass in a buffer
and a length into a function and expect data put into that buffer, e.g.
On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> Voting on the conversation around C++ return values vs. out parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
>
> For example:
>
> std::tuple<int, std::string> foo::getAAndB() {...}
>
> And call it with:
>
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
>
> Alternatively the tuple can be called like:
>
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
>
> In C++17:
>
> auto [a, b] = foo.getAAndB();
>
>
>
> Rather than:
>
> int foo::getAAndB(std::string& b) {...}
>
> Called like
>
> std::string b;
> auto a = foo.getAAndB(b);
>
> -Jake
>