+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 <mhan...@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 <jbarr...@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 <dkim...@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 <mdo...@pivotal.io >>>> >>> wrote: >>> >>>> +1 for std::string and std::wstring. >>>> >>>> Sarge >>>> >>>>> On 14 Sep, 2017, at 11:10, Mark Hanson <mhan...@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 >>>> >>>> >>> >