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 <mhan...@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 <mhan...@pivotal.io
> <mailto:mhan...@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 <jbarr...@pivotal.io
> <mailto:jbarr...@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
>
>
