Re: [gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi,

I changed CPLJSONObject/CPLJSONArray  methods string parameters to 
std::string and merged last trunk changes.


Still leave 3 methods with const char* to simplify code because 
according to standard conversion sequence, methods with input (const 
char*, const char*) parameters executes method with signature 
(std:;string&, bool):


   Add("key", "value") --> Add(std::string osName, bool bValue)
   Set("key", "value") --> Set(std::string osName, bool bValue)

See notes in pull request 
(https://github.com/OSGeo/gdal/pull/282#issuecomment-355766795).

I'm ready to merge current pull request into the trunk.

Best regards,
Dmitry

05.01.2018 23:43, Kurt Schwehr пишет:

My preference (and not speaking for the gdal community) for C++ classes
would be:

1. replace const char * -> const std::string &
2. replace CPLString -> std::string

std::string GetString(const std::string , const std::string
 = "") const;

This is where it would be good to get input from others.

I base the above on maximizing safety while trying to let the compiler do
its best job at optimizing.  Then in about 2022, we can see about
std::string_view :(

On Fri, Jan 5, 2018 at 12:26 PM, Dmitry Baryshnikov 
wrote:


Hi Kurt,

Can you explain what should be done in PR?

Do you mean to replace all const char* to?

1. const char* -> const CPLString &

const char *GetString(const char *pszName, const char *pszDefault = "")
const; ->

CPLString GetString(const CPLString , const CPLString  =
"") const;

or

2. const char* -> const std::string &

const char *GetString(const char *pszName, const char *pszDefault = "")
const; ->

std::string GetString(const std::string , const std::string
 = "") const;

or?

Best regards,
 Dmitry

05.01.2018 18:54, Kurt Schwehr пишет:

+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.
https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies  
 wrote:


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 
inhttps://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov  

wrote:


Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request https://github.com/OSGeo/gdal/
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 
listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev




--
Sean Gillies

___
gdal-dev mailing 
listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev








___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Kurt Schwehr]

Andrew,

My take:

GDAL is a not a place to look for good modern C++ code.  And there is a of
old style C++ baked into the APIs, so drivers are particularly tough.

You can look for use of unique_ptr for some code that is heading in that
direction.

The other general problem with C++ code in GDAL is that it wasn't designed
with C++ testing in mind.  I've broken headers out of some of the drivers
so I can skip past the GDALOpen/Identify interfaces and test inside the
member functions.

You can look through
https://github.com/schwehr/gdal-autotest2/tree/master/cpp but most of that
code is pretty different as it is mostly tests.

GEOS is starting to modernize so you can look some there, but also isn't
particularly strong C++11 (yet)

A good place to start is with project style guides.  There are many around
with different takes.  The one I work to is:

https://google.github.io/styleguide/cppguide.html



On Sat, Jan 6, 2018 at 3:58 AM, Andrew C Aitchison 
wrote:

> On Fri, 5 Jan 2018, Kurt Schwehr wrote:
>
> * 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.
>>
>> https://stackoverflow.com/questions/6006860/why-should-one-
>> not-derive-from-c-std-string-class
>>
>
> Can you point me to some good examples of good pure C++ code in GDAL
> - ideally driver code ? The driver tutorial
>   http://www.gdal.org/gdal_drivertut.html
> is full of pszFilename and other psz variables.
>
> When I taught myself C++ in 1992 std::string did not exist,
> and my gdal work is my only C++ practice since 1993.
> In my exploration of gdal code I have seen very little use of std::string
> and plenty of CPLString; it would be a great help to have good examples to
> copy.
>
> --
> Andrew C. Aitchison Cambridge, UK
> and...@aitchison.me.uk
>
>
>


-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Andrew C Aitchison]

On Fri, 5 Jan 2018, Kurt Schwehr wrote:


* 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.

https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class


Can you point me to some good examples of good pure C++ code in GDAL
- ideally driver code ? The driver tutorial
  http://www.gdal.org/gdal_drivertut.html
is full of pszFilename and other psz variables.

When I taught myself C++ in 1992 std::string did not exist,
and my gdal work is my only C++ practice since 1993.
In my exploration of gdal code I have seen very little use of std::string
and plenty of CPLString; it would be a great help to have good examples to 
copy.


--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Mateusz Loskot]

On 5 January 2018 at 21:43, Kurt Schwehr  wrote:
> My preference (and not speaking for the gdal community) for C++ classes
> would be:
>
> 1. replace const char * -> const std::string &
> 2. replace CPLString -> std::string

+1

> Then in about 2022, we can see about std::string_view :(

+1

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Kurt Schwehr]

My preference (and not speaking for the gdal community) for C++ classes
would be:

1. replace const char * -> const std::string &
2. replace CPLString -> std::string

std::string GetString(const std::string , const std::string
 = "") const;

This is where it would be good to get input from others.

I base the above on maximizing safety while trying to let the compiler do
its best job at optimizing.  Then in about 2022, we can see about
std::string_view :(

On Fri, Jan 5, 2018 at 12:26 PM, Dmitry Baryshnikov 
wrote:

> Hi Kurt,
>
> Can you explain what should be done in PR?
>
> Do you mean to replace all const char* to?
>
> 1. const char* -> const CPLString &
>
> const char *GetString(const char *pszName, const char *pszDefault = "")
> const; ->
>
> CPLString GetString(const CPLString , const CPLString  =
> "") const;
>
> or
>
> 2. const char* -> const std::string &
>
> const char *GetString(const char *pszName, const char *pszDefault = "")
> const; ->
>
> std::string GetString(const std::string , const std::string
>  = "") const;
>
> or?
>
> Best regards,
> Dmitry
>
> 05.01.2018 18:54, Kurt Schwehr пишет:
>
> +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.
> https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class
>
> -kurt
>
> On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies  
>  wrote:
>
>
> 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 
> inhttps://github.com/miloyip/nativejson-benchmark.
>
>
> On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov  
> 
> wrote:
>
>
> Hi everybody,
>
> Happy new year and lot of success in 2018!
>
> I would like to discuss my pull request https://github.com/OSGeo/gdal/
> 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 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> Sean Gillies
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>


-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi Kurt,

Can you explain what should be done in PR?

Do you mean to replace all const char* to?

1. const char* -> const CPLString &

   const char *GetString(const char *pszName, const char *pszDefault =
   "") const; ->

   CPLString GetString(const CPLString , const CPLString
= "") const;

or

2. const char* -> const std::string &

   const char *GetString(const char *pszName, const char *pszDefault =
   "") const; ->

   std::string GetString(const std::string , const std::string
= "") const;

or?

Best regards,
Dmitry

05.01.2018 18:54, Kurt Schwehr пишет:

+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.

https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies  wrote:


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
https://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov 
wrote:


Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request https://github.com/OSGeo/gdal/
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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev




--
Sean Gillies

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev






___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi Sean,

First of all I agreed with Kurt. Json-c is GDAL internal library and had 
inspected by fuzzer.


Also json-c widely used in GDAL:

gdal/gcore
gdal/ogr/ogrsf_frmts/carto
gdal/ogr/ogrsf_frmts/amigocloud
gdal/ogr/ogrsf_frmts/cloudant
gdal/ogr/ogrsf_frmts/plscenes
gdal/ogr/ogrsf_frmts/geojson
gdal/ogr/ogrsf_frmts/gmlas
gdal/ogr/ogrsf_frmts/elastic
gdal/ogr/ogrsf_frmts/couchdb
gdal/ogr
gdal/frmts/rda
gdal/frmts/arg
gdal/frmts/mbtiles
gdal/frmts/plmosaic
gdal/frmts/pds

It's big work to replace json-c in all code smoothly.

Best regards,
Dmitry

05.01.2018 19:05, Kurt Schwehr пишет:

I think the more important factors than speed for a C++ lib are: security,
stability, maintainability, and memory usage (low stack usage and
constrainable heap).

I really don't want to have us go through yet more piles of fuzzer bugs for
a library we depend on.  It would be nice to have that already done well by
the lib.

On Fri, Jan 5, 2018 at 7:54 AM, Kurt Schwehr  wrote:


+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.
   https://stackoverflow.com/questions/6006860/why-should-
one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies  wrote:


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
https://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov 

Re: [gdal-dev] CPLJSONDocument

[Kurt Schwehr]

I think the more important factors than speed for a C++ lib are: security,
stability, maintainability, and memory usage (low stack usage and
constrainable heap).

I really don't want to have us go through yet more piles of fuzzer bugs for
a library we depend on.  It would be nice to have that already done well by
the lib.

On Fri, Jan 5, 2018 at 7:54 AM, Kurt Schwehr  wrote:

> +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.
>   https://stackoverflow.com/questions/6006860/why-should-
> one-not-derive-from-c-std-string-class
>
> -kurt
>
> On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies  wrote:
>
>> 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
>> https://github.com/miloyip/nativejson-benchmark.
>>
>>
>> On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov > > wrote:
>>
>>> Hi everybody,
>>>
>>> Happy new year and lot of success in 2018!
>>>
>>> I would like to discuss my pull request https://github.com/OSGeo/gdal/
>>> 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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Kurt Schwehr]

+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.

https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies  wrote:

> 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
> https://github.com/miloyip/nativejson-benchmark.
>
>
> On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov 
> wrote:
>
>> Hi everybody,
>>
>> Happy new year and lot of success in 2018!
>>
>> I would like to discuss my pull request https://github.com/OSGeo/gdal/
>> 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
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> Sean Gillies
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Sean Gillies]

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
https://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov 
wrote:

> Hi everybody,
>
> Happy new year and lot of success in 2018!
>
> I would like to discuss my pull request https://github.com/OSGeo/gdal/
> 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
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CPLJSONDocument

[Even Rouault]

Dmitry,

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

I did some review of your code. If nobody has extra remarks in the 
next days, just merge it.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request 
https://github.com/OSGeo/gdal/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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev