<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Kurt,</p>
    <p>Can you explain what should be done in PR?</p>
    <p>Do you mean to replace all const char* to?<br>
    </p>
    <p>1. const char* -> const CPLString &</p>
    <blockquote>
      <p>const char *GetString(const char *pszName, const char
        *pszDefault = "") const; -></p>
      <p>CPLString GetString(const CPLString &soName, const
        CPLString &soDefault = "") const;</p>
    </blockquote>
    <p>or<br>
    </p>
    <p>2. const char* -> const std::string &</p>
    <blockquote>
      <p>const char *GetString(const char *pszName, const char
        *pszDefault = "") const; -></p>
      <p>std::string GetString(const std::string &soName, const
        std::string &soDefault = "") const;</p>
    </blockquote>
    <p>or?<br>
    </p>
    <pre class="moz-signature" cols="72">Best regards,
    Dmitry</pre>
    <div class="moz-cite-prefix">05.01.2018 18:54, Kurt Schwehr пишет:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACmBxytuR-4n-gzQw7RLT3OaAkfTakb2bdvQ0i1KP9diPBsNsA@mail.gmail.com">
      <pre wrap="">+1 for wrapping the old C code in some cleaner abstractions!

But +10 for switching to a from the ground up C++ JSON library unless there
are clear reasons for a core C library (I don't think there are)

If we are talking about this kind of code, there are several things that
have bugged me in general about GDAL for a long time.

* Passing char *psz yada all over the place in pure C++ code.  A const
std::string is usually not a noticeable expense and is a lot safer
* CPLString when std::string will do just fine.  And we can write free
functions to operate on strings.  I'm generally bothered by subclassing of
std::string as CPLString.  After reading large amounts of C++ code, I think
it adds more confusion than it ever helps over having clean free
functions.  Interop and analysis with CPLString's is no fun.

<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class">https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class</a>

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies <a class="moz-txt-link-rfc2396E" href="mailto:sean@mapbox.com"><sean@mapbox.com></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Hi Dmitry,

I scanned the PR and it seems reasonable to me. I'm barely a C++
programmer at all and it's clear to me, more clear than before. That said,
I'm not a fan of wrapping things that could be replaced. Have you looked
into whether a more performant C++ JSON library could be used? I haven't
run the benchmarks, but json-c compares pretty poorly to others in
<a class="moz-txt-link-freetext" href="https://github.com/miloyip/nativejson-benchmark">https://github.com/miloyip/nativejson-benchmark</a>.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov <a class="moz-txt-link-rfc2396E" href="mailto:bishop.dev@gmail.com"><bishop.dev@gmail.com></a>
wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="">Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/">https://github.com/OSGeo/gdal/</a>
pull/282

I created a thin wrapper around the json-c library which wide using in
GDAL.

This is C++ interface which hides C memory management and provides nice
API. The web or disk json documents reading chunk by chunk with progress
indication also added.

In future, the json-c can be easily switch to something other without
breaking the existing code.

The CPLJSONDocument/CPLJSONObject/CPLJSONArray usage examples can be
found in frmts/pds driver and c++ unit test in autotest/cpp/test_cpl.cpp.

Is this ready to merge into the trunk? Any objections?

Best regards,
    Dmitry


_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
        </blockquote>
        <pre wrap="">



--
Sean Gillies

_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>

</pre>
      </blockquote>
      <pre wrap="">


</pre>
    </blockquote>
    <br>
  </body>
</html>