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 <jbarr...@pivotal.io> wrote:
> On Fri, Sep 15, 2017 at 10:33 AM Mark Hanson <mhan...@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
>
