Basic docs on the C++11 tuple use for multiple return types:
http://en.cppreference.com/w/cpp/utility/tuple
In C++11 we would have:
std::tuple<int, std::string> foo::getAAndB() {...}
And call it with:
int a;
std::string b;
std::tie(a, b) = foo.getAAndB();
While this isn't super pretty I would argue it is more readable than.
std::string b;
auto a = foo.getAAndB(b);
I believe this is unclear when reading that b is an out variable rather
than passing empty string value to the function.
And certainly easier to understand than:
int a;
std::string b;
foo.getAAndB(a, b);
Again, is a and be inadvertently uninitialized?
Alternatively the tuple can be called like:
auto r = foo.getAAndB();
auto a = std::get<0>(r);
auto b = std::get<1>(r);
Another interesting blog on the issue:
https://dzone.com/articles/returning-multiple-values-from-functions-in-c
-Jake
On Mon, Oct 2, 2017 at 9:07 AM Jacob Barrett <jbarr...@pivotal.io> wrote:
> We are already in contention with our style guide on many items. I suggest
> we use it as a guideline only and establish our own rules. The more
> research into the Google C++ guide is really driven by legacy C/C++ issues
> at Google.
>
> Regarding the in/out issue I am for multiple return types so that we
> migrate to a more functional programming style. An interesting article I
> read last week on this issue sheds some good light on why,
> https://www.fluentcpp.com/2016/11/22/make-your-functions-functional/.
>
> As a bonus, once we go C++17 (in 2020ish I am sure) we can use auto
> structured return values.
> auto [a, b] = foo.getAAndB();
>
> -Jake
>
>
> On Wed, Sep 27, 2017 at 1:14 PM David Kimura <dkim...@pivotal.io> wrote:
>
>> I forgot to mention, and it's probably worth noting, that passing
>> non-const
>> ref knowingly defies our style-guide.
>>
>> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
>>
>> Thanks,
>> David
>>
>> On Wed, Sep 27, 2017 at 12:32 PM, Ernest Burghardt <eburgha...@pivotal.io
>> >
>> wrote:
>>
>> > Currently we have a mix of the counter argument...
>> >
>> > we use return values and you have to call the explicitly named methods:
>> > double* readDoubleArray(const char* fieldName, int32_t& length)
>> > int64_t* readLongArray(const char* fieldName, int32_t& length)
>> >
>> > I'm good with non-const refs in-out to the specific method calls OR
>> > overload readArray and different return values...
>> >
>> > EB
>> >
>> > On Wed, Sep 27, 2017 at 1:27 PM, Michael William Dodge <
>> mdo...@pivotal.io>
>> > wrote:
>> >
>> > > I like the idea of using non-const references for in-out parameters
>> only
>> > > and using tuples for the cases where there are multiple out
>> parameters.
>> > > Yes, the return type does not participate in overload resolution but I
>> > > don't think there would be many cases where that would be an issue.
>> (But
>> > I
>> > > haven't done any research so that's just a WAG.)
>> > >
>> > > Sarge
>> > >
>> > > > On 27 Sep, 2017, at 12:22, David Kimura <dkim...@pivotal.io> wrote:
>> > > >
>> > > > Is there a use case in our C++ client code to ever use out
>> parameters?
>> > > >
>> > > > Currently code uses out parameters to return multiple values from a
>> > > > function. [1]
>> > > >
>> > > > virtual int64_t* PdxReader::readLongArray(const char* fieldName,
>> > int32_t&
>> > > > length) = 0;
>> > > >
>> > > >
>> > > > In this case, we could return a tuple instead. I think the
>> advantage
>> > of
>> > > > this is it doesn't force a separation between the variable
>> declaration
>> > > and
>> > > > assignment, which may lead to spaghetti code. I think avoiding out
>> > > > parameters also leads to more well defined behavior. What would one
>> > > expect
>> > > > if they called getCqListeners with an already partially populated
>> > vector?
>> > > > [2]
>> > > >
>> > > > virtual void CqAttributes::getCqListeners(std::vector<CqListenerPtr&
>> > v)
>> > > = 0;
>> > > >
>> > > >
>> > > > As a counter argument, could function overload resolution be a valid
>> > use
>> > > > case of out parameters? In PdxReader::readType methods, Type seems
>> > > > redundant. As a user, why should I have to call
>> > > readLongArray(int64_t[]&)
>> > > > rather than just call read(int64_t[]&)? In this case, if we didn't
>> use
>> > > out
>> > > > parameter our signature clashes with other read methods.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > Thanks,
>> > > > David
>> > > >
>> > > > [1]
>> > > > https://github.com/apache/geode-native/blob/
>> > > 44635ffa95926c9cffecc1dcaac02fb3012d1eef/cppcache/include/
>> > > geode/PdxReader.hpp#L288
>> > > > [2]
>> > > > https://github.com/apache/geode-native/blob/
>> > > 44635ffa95926c9cffecc1dcaac02fb3012d1eef/cppcache/include/
>> > > geode/CqAttributes.hpp#L60
>> > >
>> > >
>> >
>>
>
