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