You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by David Kimura <dk...@pivotal.io> on 2017/09/27 19:22:11 UTC
[DISCUSS] Using out parameters and its effects on function overload resolution
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
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by Jacob Barrett <jb...@pivotal.io>.
On Mon, Oct 2, 2017 at 12:19 PM David Kimura <dk...@pivotal.io> wrote:
> The other question though is, could function overload resolution be a valid
> use case for out variables (particularly in PdxReader, for example)?
I am against exceptions to rules unless the exception is more readable. In
this case I don't think the exception to our rule, of using return values
only and no out params, gains anything for single return types that differ.
auto i = input.readInt();
auto b = input.readByte();
Is more expressive and readable than:
int i;
input.read(i);
char b;
input.readByte(b);
Templates could solve the problem, but I am not sure it is more expressive
or easier to read:
auto i = input.read<int32_t>();
auto b = input.read<int16_t>();
It also runs into issues of ballooning specializations for each of the C++
types. See: http://coliru.stacked-crooked.com/a/33ca43ee0ed59a7f
<http://coliru.stacked-crooked.com/a/be6ef60194d4e0db>
I think in this case since the serializer is dealing with our "GemFire
Types" which just happen to be Java types then we should be descriptive in
those terms therefor readInt, readLong, readShort, etc. wins in my book.
-Jake
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by David Kimura <dk...@pivotal.io>.
I agree. I think returning tuple flows better and seems to be the way the
language is progressing.
Also, I think it's probably even more efficient than using out variable.
Using out variable we'd pay the cost of the default constructor and then
the cost populating any state which is essentially equivalent to a copy
constructor. While returning tuples we can let the compiler perform RVO
and the standard library perform small object optimization.
The other question though is, could function overload resolution be a valid
use case for out variables (particularly in PdxReader, for example)?
Thanks,
David
On Mon, Oct 2, 2017 at 10:56 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> 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 <jb...@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 <dk...@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 <
> eburghardt@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 <
> >> mdodge@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 <dk...@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
> >> > >
> >> > >
> >> >
> >>
> >
>
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <jb...@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 <dk...@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 <eburghardt@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 <
>> mdodge@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 <dk...@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
>> > >
>> > >
>> >
>>
>
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <dk...@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 <eb...@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 <
> mdodge@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 <dk...@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
> > >
> > >
> >
>
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by David Kimura <dk...@pivotal.io>.
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 <eb...@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 <md...@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 <dk...@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
> >
> >
>
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by Ernest Burghardt <eb...@pivotal.io>.
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 <md...@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 <dk...@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
>
>
Re: [DISCUSS] Using out parameters and its effects on function
overload resolution
Posted by Michael William Dodge <md...@pivotal.io>.
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 <dk...@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