geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael William Dodge <mdo...@pivotal.io>
Subject Re: [VOTE] C++ standardize on return values only
Date Wed, 18 Oct 2017 22:24:41 GMT
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 <mhanson@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 <mailto:mhanson@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 <mailto:jbarrett@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
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message