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 <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
>
>
