You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Mark Hanson <mh...@pivotal.io> on 2017/09/15 17:18:21 UTC
[VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
So we have two approaches as their has been a veto on w_string, so it will not be used.
Approach 1) std::string str = object.to_string();
Approach 2) std::string str = std::to_string(object);
Please vote of your preferred.
Thanks,
Mark
> On Sep 14, 2017, at 12:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> Don't use std::wstring EVER. The std::wstring has a platform dependent
> storage class. This means on Windows it is 32bits and Linux it is 16bits.
> None of the std::string types, and there are more than std::wstring, define
> an encoding, so would the wstring be UTF-16, UC-2, UTF-32, UC-4, or some
> other local non-unicode codepage. It gets nasty fast!
>
> If you only support std::string and require the all std::string's be
> encoded with UTF-8 then things get real clear really fast. Yes there is
> some overhead in converting to UC-4 for calling windows system calls that
> want Unicode 32-bit std::wstring but we already had that overhead since
> almost all strings in NC were actually 8-bit UTF-8 std::string. And since
> almost all those are ASCII strings and UTF-8 can encode ASCII without
> overhead we are good to go!
>
> So to simply we would change Serializable::toString to only a std::string.
>
> class Serializable {
> ...
> virtual const std::string& toString() const noexcept;
> }
>
> So the example use would be:
>
> auto myObject = region.get("myObject"); // auto = std::shared_ptr<MyObject>
> auto myString = myObject->toString(); // auto = std::string
> std::cout << myString;
>
> Even nicer may be to implement a default << operator for Serializable the
> outputs the toString so we can do:
>
> std::cout << region.get("myObject");
>
> As for exporting a to_string into the std namespace, I think that is one
> that is actually forbidden unlike std::hash/equal_to. I feel like I found
> that when trying to output std::chrono::duration objects to stream. Can you
> double check that it is allowed?
>
> -Jake
>
>
>
> On Thu, Sep 14, 2017 at 11:30 AM David Kimura <dk...@pivotal.io> wrote:
>
>> Seems like a good idea.
>>
>> Here's a quick thought - I think c++11 is not really an obj.toString() kind
>> of language (like Java or C#). Would it make sense to add std::to_string()
>> and std::to_wstring() equivalents for CacheableString? This might mean
>> implementing following functions:
>>
>> std::string to_string(CacheableString value);
>> std::wstring to_wstring(CacheableString value);
>>
>> So that we can do something like:
>>
>> std::cout << std::to_wstring(pdxser);
>>
>> Thanks,
>> David
>>
>> On Thu, Sep 14, 2017 at 11:10 AM, Michael William Dodge <mdodge@pivotal.io
>>>
>> wrote:
>>
>>> +1 for std::string and std::wstring.
>>>
>>> Sarge
>>>
>>>> On 14 Sep, 2017, at 11:10, Mark Hanson <mh...@pivotal.io> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I wanted to broach the subject of moving away from moving away from
>>> CacheableStringPtrs for the toString representation of Serializable. It
>>> would seem desirable to move to std::string and std::wstring to use more
>>> basic types that would be faster to log and the code would be simpler
>> for a
>>> user.
>>>>
>>>> Are there any opinions on this subject?
>>>>
>>>> Here is a before and after look at a chunk of code
>>>>
>>>> Before
>>>>
>>>> CacheableStringPtr ptr = pdxser->toString();
>>>> if (ptr->isWideString()) {
>>>> printf(" query idx %d pulled object %S :: \n", i,
>>>> ptr->asWChar());
>>>> } else {
>>>> printf(" query idx %d pulled object %s :: \n", i,
>>>> ptr->asChar());
>>>> }
>>>>
>>>> After
>>>>
>>>>
>>>> if (pdxser->isWideString()) {
>>>> std::cout << " query idx “ << i << "pulled object ” <<
>>> pdxser->toWString() << std::endl;
>>>> } else {
>>>> std::cout << " query idx “ << i << "pulled object ” <<
>>> pdxser->toString() << std::endl;
>>>> }
>>>>
>>>>
>>>> Thanks,
>>>> Mark
>>>
>>>
>>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Mark Hanson <mh...@pivotal.io>.
+1 for Approach 1 based on the fact that it will have a compile error if you don’t implement it, and it is more object oriented.
Thanks,
Mark
> On Sep 15, 2017, at 10:18 AM, Mark Hanson <mh...@pivotal.io> wrote:
>
> So we have two approaches as their has been a veto on w_string, so it will not be used.
>
> Approach 1) std::string str = object.to_string();
> Approach 2) std::string str = std::to_string(object);
>
> Please vote of your preferred.
>
> Thanks,
> Mark
>
>
>> On Sep 14, 2017, at 12:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>
>> Don't use std::wstring EVER. The std::wstring has a platform dependent
>> storage class. This means on Windows it is 32bits and Linux it is 16bits.
>> None of the std::string types, and there are more than std::wstring, define
>> an encoding, so would the wstring be UTF-16, UC-2, UTF-32, UC-4, or some
>> other local non-unicode codepage. It gets nasty fast!
>>
>> If you only support std::string and require the all std::string's be
>> encoded with UTF-8 then things get real clear really fast. Yes there is
>> some overhead in converting to UC-4 for calling windows system calls that
>> want Unicode 32-bit std::wstring but we already had that overhead since
>> almost all strings in NC were actually 8-bit UTF-8 std::string. And since
>> almost all those are ASCII strings and UTF-8 can encode ASCII without
>> overhead we are good to go!
>>
>> So to simply we would change Serializable::toString to only a std::string.
>>
>> class Serializable {
>> ...
>> virtual const std::string& toString() const noexcept;
>> }
>>
>> So the example use would be:
>>
>> auto myObject = region.get("myObject"); // auto = std::shared_ptr<MyObject>
>> auto myString = myObject->toString(); // auto = std::string
>> std::cout << myString;
>>
>> Even nicer may be to implement a default << operator for Serializable the
>> outputs the toString so we can do:
>>
>> std::cout << region.get("myObject");
>>
>> As for exporting a to_string into the std namespace, I think that is one
>> that is actually forbidden unlike std::hash/equal_to. I feel like I found
>> that when trying to output std::chrono::duration objects to stream. Can you
>> double check that it is allowed?
>>
>> -Jake
>>
>>
>>
>> On Thu, Sep 14, 2017 at 11:30 AM David Kimura <dk...@pivotal.io> wrote:
>>
>>> Seems like a good idea.
>>>
>>> Here's a quick thought - I think c++11 is not really an obj.toString() kind
>>> of language (like Java or C#). Would it make sense to add std::to_string()
>>> and std::to_wstring() equivalents for CacheableString? This might mean
>>> implementing following functions:
>>>
>>> std::string to_string(CacheableString value);
>>> std::wstring to_wstring(CacheableString value);
>>>
>>> So that we can do something like:
>>>
>>> std::cout << std::to_wstring(pdxser);
>>>
>>> Thanks,
>>> David
>>>
>>> On Thu, Sep 14, 2017 at 11:10 AM, Michael William Dodge <mdodge@pivotal.io
>>>>
>>> wrote:
>>>
>>>> +1 for std::string and std::wstring.
>>>>
>>>> Sarge
>>>>
>>>>> On 14 Sep, 2017, at 11:10, Mark Hanson <mh...@pivotal.io> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I wanted to broach the subject of moving away from moving away from
>>>> CacheableStringPtrs for the toString representation of Serializable. It
>>>> would seem desirable to move to std::string and std::wstring to use more
>>>> basic types that would be faster to log and the code would be simpler
>>> for a
>>>> user.
>>>>>
>>>>> Are there any opinions on this subject?
>>>>>
>>>>> Here is a before and after look at a chunk of code
>>>>>
>>>>> Before
>>>>>
>>>>> CacheableStringPtr ptr = pdxser->toString();
>>>>> if (ptr->isWideString()) {
>>>>> printf(" query idx %d pulled object %S :: \n", i,
>>>>> ptr->asWChar());
>>>>> } else {
>>>>> printf(" query idx %d pulled object %s :: \n", i,
>>>>> ptr->asChar());
>>>>> }
>>>>>
>>>>> After
>>>>>
>>>>>
>>>>> if (pdxser->isWideString()) {
>>>>> std::cout << " query idx “ << i << "pulled object ” <<
>>>> pdxser->toWString() << std::endl;
>>>>> } else {
>>>>> std::cout << " query idx “ << i << "pulled object ” <<
>>>> pdxser->toString() << std::endl;
>>>>> }
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Mark
>>>>
>>>>
>>>
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Mark Hanson <mh...@pivotal.io>.
My vote is unchanged…
+1 for on the object.
Thanks,
Mark
> On Sep 15, 2017, at 10:47 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> On Fri, Sep 15, 2017 at 10:40 AM David Kimura <dk...@pivotal.io> wrote:
>
>> Actually, it looks like Jake is right. According to documentation it's
>> undefined behavior since it's not a template specialization.
>>
>> http://en.cppreference.com/w/cpp/language/extending_std
>>
>>
> Oh yeah, I know I rejected the idea for a reason the first time. Thanks for
> pointing out the template specialization issue.
>
> -Jake
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Jacob Barrett <jb...@pivotal.io>.
On Fri, Sep 15, 2017 at 10:40 AM David Kimura <dk...@pivotal.io> wrote:
> Actually, it looks like Jake is right. According to documentation it's
> undefined behavior since it's not a template specialization.
>
> http://en.cppreference.com/w/cpp/language/extending_std
>
>
Oh yeah, I know I rejected the idea for a reason the first time. Thanks for
pointing out the template specialization issue.
-Jake
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by David Kimura <dk...@pivotal.io>.
Actually, it looks like Jake is right. According to documentation it's
undefined behavior since it's not a template specialization.
http://en.cppreference.com/w/cpp/language/extending_std
Thanks,
David
On Fri, Sep 15, 2017 at 10:37 AM, Ernest Burghardt <eb...@pivotal.io>
wrote:
> cool that we could export into the std namespace, but as a library I don't
> think it is a good idea as a user of our library might have done the same
> thing and that is a situation we can easily/pro-actively avoid....
>
> +1 object::toString()
>
> On Fri, Sep 15, 2017 at 11:33 AM, Mark Hanson <mh...@pivotal.io> wrote:
>
> > Comments inline….
> > > On Sep 15, 2017, at 10:25 AM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >
> > > -1 to all, comments below.
> > >
> > >
> > >> On Sep 15, 2017, at 10:18 AM, Mark Hanson <mh...@pivotal.io> wrote:
> > >>
> > >> So we have two approaches as their has been a veto on w_string, so it
> > will not be used.
> > >
> > > Who said anything about veto? Nobody has veto authority. I simply
> stated
> > and opinion on the use of wstring based on my research in the past.
> > >
> >
> > Ok, not vetoed.
> >
> > >> Approach 1) std::string str = object.to_string();
> > > To remain consistent with the APIs use of camel case this should be
> > toString();
> > >
> >
> > Uh, yeah. Concept not code...
> >
> > >
> > >> Approach 2) std::string str = std::to_string(object);
> > >
> > > Nobody countered my assertion that this is not legal to export into std
> > names space.
> > >
> >
> > class blobject
> > {
> > bool blobBool;
> > };
> >
> >
> > namespace std {
> > std::string to_String(blobject * blob)
> > {
> > return std::string("works");
> > }
> > }
> >
> >
> > int main() {
> >
> > blobject * blob = new blobject();
> > std::string str = std::to_String(blob);
> > std::cout << "Hello, World! " << "value = " << str << std::endl;
> > return 0;
> > }
> > /Users/mhanson/CLionProjects/untitled1/cmake-build-debug/untitled1
> > Hello, World! value = works
> >
> > Process finished with exit code 0
> >
> >
> > > -Jake
> > >
> > >
> >
> >
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Ernest Burghardt <eb...@pivotal.io>.
cool that we could export into the std namespace, but as a library I don't
think it is a good idea as a user of our library might have done the same
thing and that is a situation we can easily/pro-actively avoid....
+1 object::toString()
On Fri, Sep 15, 2017 at 11:33 AM, Mark Hanson <mh...@pivotal.io> wrote:
> Comments inline….
> > On Sep 15, 2017, at 10:25 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > -1 to all, comments below.
> >
> >
> >> On Sep 15, 2017, at 10:18 AM, Mark Hanson <mh...@pivotal.io> wrote:
> >>
> >> So we have two approaches as their has been a veto on w_string, so it
> will not be used.
> >
> > Who said anything about veto? Nobody has veto authority. I simply stated
> and opinion on the use of wstring based on my research in the past.
> >
>
> Ok, not vetoed.
>
> >> Approach 1) std::string str = object.to_string();
> > To remain consistent with the APIs use of camel case this should be
> toString();
> >
>
> Uh, yeah. Concept not code...
>
> >
> >> Approach 2) std::string str = std::to_string(object);
> >
> > Nobody countered my assertion that this is not legal to export into std
> names space.
> >
>
> class blobject
> {
> bool blobBool;
> };
>
>
> namespace std {
> std::string to_String(blobject * blob)
> {
> return std::string("works");
> }
> }
>
>
> int main() {
>
> blobject * blob = new blobject();
> std::string str = std::to_String(blob);
> std::cout << "Hello, World! " << "value = " << str << std::endl;
> return 0;
> }
> /Users/mhanson/CLionProjects/untitled1/cmake-build-debug/untitled1
> Hello, World! value = works
>
> Process finished with exit code 0
>
>
> > -Jake
> >
> >
>
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Jacob Barrett <jb...@pivotal.io>.
+1 for:
std::string toString() const noexcept;
On Fri, Sep 15, 2017 at 10:52 AM Jacob Barrett <jb...@pivotal.io> wrote:
> On Fri, Sep 15, 2017 at 10:50 AM Ernest Burghardt <eb...@pivotal.io>
> wrote:
>
>> Not convinced or grok'g doing both... what is the benefit of adding the
>> std::to_string()'s?
>>
>
> Convenience only, but as David pointed out it is not allowed.
>
> -Jake
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Ernest Burghardt <eb...@pivotal.io>.
okay so we have +1s on object.toString()
any dissenting opinions?
On Fri, Sep 15, 2017 at 11:52 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> On Fri, Sep 15, 2017 at 10:50 AM Ernest Burghardt <eb...@pivotal.io>
> wrote:
>
> > Not convinced or grok'g doing both... what is the benefit of adding the
> > std::to_string()'s?
> >
>
> Convenience only, but as David pointed out it is not allowed.
>
> -Jake
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Jacob Barrett <jb...@pivotal.io>.
On Fri, Sep 15, 2017 at 10:50 AM Ernest Burghardt <eb...@pivotal.io>
wrote:
> Not convinced or grok'g doing both... what is the benefit of adding the
> std::to_string()'s?
>
Convenience only, but as David pointed out it is not allowed.
-Jake
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Ernest Burghardt <eb...@pivotal.io>.
Not convinced or grok'g doing both... what is the benefit of adding the
std::to_string()'s?
On Fri, Sep 15, 2017 at 11:46 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> On Fri, Sep 15, 2017 at 10:33 AM Mark Hanson <mh...@pivotal.io> wrote:
>
> > class blobject
> > {
> > bool blobBool;
> > };
> >
> >
> > namespace std {
> > std::string to_String(blobject * blob)
> > {
> > return std::string("works");
> > }
> > }
> >
> >
> > int main() {
> >
> > blobject * blob = new blobject();
> > std::string str = std::to_String(blob);
> > std::cout << "Hello, World! " << "value = " << str << std::endl;
> > return 0;
> > }
> > /Users/mhanson/CLionProjects/untitled1/cmake-build-debug/untitled1
> > Hello, World! value = works
> >
>
> Yes, this asserts it is possible, which was not in question. My assertion
> is that the specification forbids exporting code into the std namespace
> with very few exceptions.
>
> http://en.cppreference.com/w/cpp/language/extending_std
>
> In another review of the specification extending the std::to_string is
> allowed assuming that it is only done for user defined types and none of
> the std types. In our use case it would be allowed.
>
> I would suggest however that we keep Serializable::toString for consistency
> with previous API and implement:
> namespace std {
> std::string to_string(const Serializable& object) {
> return object.toString();
> }
> std::string to_string(const Serializable* object) {
> return object->toString();
> }
> std::string to_string(const std::shared_ptr<Serializable>& object) {
> return object->toString();
> }
> std::string to_string(const std::unique_ptr<Serializable>& object) {
> return object->toString();
> }
> }
>
> -Jake
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Jacob Barrett <jb...@pivotal.io>.
On Fri, Sep 15, 2017 at 10:33 AM Mark Hanson <mh...@pivotal.io> wrote:
> class blobject
> {
> bool blobBool;
> };
>
>
> namespace std {
> std::string to_String(blobject * blob)
> {
> return std::string("works");
> }
> }
>
>
> int main() {
>
> blobject * blob = new blobject();
> std::string str = std::to_String(blob);
> std::cout << "Hello, World! " << "value = " << str << std::endl;
> return 0;
> }
> /Users/mhanson/CLionProjects/untitled1/cmake-build-debug/untitled1
> Hello, World! value = works
>
Yes, this asserts it is possible, which was not in question. My assertion
is that the specification forbids exporting code into the std namespace
with very few exceptions.
http://en.cppreference.com/w/cpp/language/extending_std
In another review of the specification extending the std::to_string is
allowed assuming that it is only done for user defined types and none of
the std types. In our use case it would be allowed.
I would suggest however that we keep Serializable::toString for consistency
with previous API and implement:
namespace std {
std::string to_string(const Serializable& object) {
return object.toString();
}
std::string to_string(const Serializable* object) {
return object->toString();
}
std::string to_string(const std::shared_ptr<Serializable>& object) {
return object->toString();
}
std::string to_string(const std::unique_ptr<Serializable>& object) {
return object->toString();
}
}
-Jake
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Mark Hanson <mh...@pivotal.io>.
Comments inline….
> On Sep 15, 2017, at 10:25 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> -1 to all, comments below.
>
>
>> On Sep 15, 2017, at 10:18 AM, Mark Hanson <mh...@pivotal.io> wrote:
>>
>> So we have two approaches as their has been a veto on w_string, so it will not be used.
>
> Who said anything about veto? Nobody has veto authority. I simply stated and opinion on the use of wstring based on my research in the past.
>
Ok, not vetoed.
>> Approach 1) std::string str = object.to_string();
> To remain consistent with the APIs use of camel case this should be toString();
>
Uh, yeah. Concept not code...
>
>> Approach 2) std::string str = std::to_string(object);
>
> Nobody countered my assertion that this is not legal to export into std names space.
>
class blobject
{
bool blobBool;
};
namespace std {
std::string to_String(blobject * blob)
{
return std::string("works");
}
}
int main() {
blobject * blob = new blobject();
std::string str = std::to_String(blob);
std::cout << "Hello, World! " << "value = " << str << std::endl;
return 0;
}
/Users/mhanson/CLionProjects/untitled1/cmake-build-debug/untitled1
Hello, World! value = works
Process finished with exit code 0
> -Jake
>
>
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring
Posted by Jacob Barrett <jb...@pivotal.io>.
-1 to all, comments below.
> On Sep 15, 2017, at 10:18 AM, Mark Hanson <mh...@pivotal.io> wrote:
>
> So we have two approaches as their has been a veto on w_string, so it will not be used.
Who said anything about veto? Nobody has veto authority. I simply stated and opinion on the use of wstring based on my research in the past.
> Approach 1) std::string str = object.to_string();
To remain consistent with the APIs use of camel case this should be toString();
> Approach 2) std::string str = std::to_string(object);
Nobody countered my assertion that this is not legal to export into std names space.
-Jake
Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for
Serializable objects in debug and logging to std::string and std::wstring
Posted by Ernest Burghardt <eb...@pivotal.io>.
+1 Approach 1) std::string str = object.to_string();
On Fri, Sep 15, 2017 at 11:18 AM, Mark Hanson <mh...@pivotal.io> wrote:
> So we have two approaches as their has been a veto on w_string, so it will
> not be used.
>
> Approach 1) std::string str = object.to_string();
> Approach 2) std::string str = std::to_string(object);
>
> Please vote of your preferred.
>
> Thanks,
> Mark
>
>
> > On Sep 14, 2017, at 12:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > Don't use std::wstring EVER. The std::wstring has a platform dependent
> > storage class. This means on Windows it is 32bits and Linux it is 16bits.
> > None of the std::string types, and there are more than std::wstring,
> define
> > an encoding, so would the wstring be UTF-16, UC-2, UTF-32, UC-4, or some
> > other local non-unicode codepage. It gets nasty fast!
> >
> > If you only support std::string and require the all std::string's be
> > encoded with UTF-8 then things get real clear really fast. Yes there is
> > some overhead in converting to UC-4 for calling windows system calls that
> > want Unicode 32-bit std::wstring but we already had that overhead since
> > almost all strings in NC were actually 8-bit UTF-8 std::string. And since
> > almost all those are ASCII strings and UTF-8 can encode ASCII without
> > overhead we are good to go!
> >
> > So to simply we would change Serializable::toString to only a
> std::string.
> >
> > class Serializable {
> > ...
> > virtual const std::string& toString() const noexcept;
> > }
> >
> > So the example use would be:
> >
> > auto myObject = region.get("myObject"); // auto =
> std::shared_ptr<MyObject>
> > auto myString = myObject->toString(); // auto = std::string
> > std::cout << myString;
> >
> > Even nicer may be to implement a default << operator for Serializable the
> > outputs the toString so we can do:
> >
> > std::cout << region.get("myObject");
> >
> > As for exporting a to_string into the std namespace, I think that is one
> > that is actually forbidden unlike std::hash/equal_to. I feel like I found
> > that when trying to output std::chrono::duration objects to stream. Can
> you
> > double check that it is allowed?
> >
> > -Jake
> >
> >
> >
> > On Thu, Sep 14, 2017 at 11:30 AM David Kimura <dk...@pivotal.io>
> wrote:
> >
> >> Seems like a good idea.
> >>
> >> Here's a quick thought - I think c++11 is not really an obj.toString()
> kind
> >> of language (like Java or C#). Would it make sense to add
> std::to_string()
> >> and std::to_wstring() equivalents for CacheableString? This might mean
> >> implementing following functions:
> >>
> >> std::string to_string(CacheableString value);
> >> std::wstring to_wstring(CacheableString value);
> >>
> >> So that we can do something like:
> >>
> >> std::cout << std::to_wstring(pdxser);
> >>
> >> Thanks,
> >> David
> >>
> >> On Thu, Sep 14, 2017 at 11:10 AM, Michael William Dodge <
> mdodge@pivotal.io
> >>>
> >> wrote:
> >>
> >>> +1 for std::string and std::wstring.
> >>>
> >>> Sarge
> >>>
> >>>> On 14 Sep, 2017, at 11:10, Mark Hanson <mh...@pivotal.io> wrote:
> >>>>
> >>>> Hi All,
> >>>>
> >>>> I wanted to broach the subject of moving away from moving away from
> >>> CacheableStringPtrs for the toString representation of Serializable. It
> >>> would seem desirable to move to std::string and std::wstring to use
> more
> >>> basic types that would be faster to log and the code would be simpler
> >> for a
> >>> user.
> >>>>
> >>>> Are there any opinions on this subject?
> >>>>
> >>>> Here is a before and after look at a chunk of code
> >>>>
> >>>> Before
> >>>>
> >>>> CacheableStringPtr ptr = pdxser->toString();
> >>>> if (ptr->isWideString()) {
> >>>> printf(" query idx %d pulled object %S :: \n", i,
> >>>> ptr->asWChar());
> >>>> } else {
> >>>> printf(" query idx %d pulled object %s :: \n", i,
> >>>> ptr->asChar());
> >>>> }
> >>>>
> >>>> After
> >>>>
> >>>>
> >>>> if (pdxser->isWideString()) {
> >>>> std::cout << " query idx “ << i << "pulled object ” <<
> >>> pdxser->toWString() << std::endl;
> >>>> } else {
> >>>> std::cout << " query idx “ << i << "pulled object ” <<
> >>> pdxser->toString() << std::endl;
> >>>> }
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Mark
> >>>
> >>>
> >>
>
>