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