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
