Use of C++

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Use of C++

Even Rouault-2
Hi,

As announced previously, and given that the SQLite related thread has calmed
down (except license related discussions that aren't directly related to it),
this is the second potentially controversial topic I wanted to discuss.

To be able to handle WKT v1 and WKT v2, relying on the
object modeling of CRS, coordinate transformations and related concepts,
detailed in the ISO 19111:2018 / OGC 18-005r1 "OGC Abstract Specification:
Topic 2: Referencing by coordinates" seems an appropriate start.
See http://www.opengeospatial.org/standards/requests/166 (note: access to the
draft docx requires OGC membership currently)

ISO 19111:2018 will soon replace the current ISO 19111:2007 / OGC 08-015r2 :
http://portal.opengeospatial.org/files/?artifact_id=39049

This updated specification brings new concepts, particularly the
concept of dynamic geodetic reference frames (dynamic datums) that are going
to be fundamental for current (ITRF, WGS84) or future datums (NATRF2022 that
will replace NAD83 in the USA, ATRF in Australia ...)
In the coming months, there will be revision of WKT 2 to catch up with this
evolution of ISO 19111.
Future versions of the EPSG database will also later adapt to this.
ISO 19111 exposes the concepts with UML modelling. We also have GeoAPI
( http://www.opengeospatial.org/standards/geoapi ) that
offers Java (and in progress Python) class hierarchies. In the PROJ context,
it seems natural to opt for C++. Part of that new API will be exposed to C ,
the exact scope remains to be determined depending on the needs. To be clear,
this would not impact the status of existing proj C API, and the already
announced retirement plans of projects.h and proj_api.h.

On a more practical note, this is also the opportunity to reuse existing C++
code from GDAL (WKT tree node building).

I know that this choice of C++ could be perceived as an obstacle for
portability of PROJ, but I don't think this is an actual concern in practice.
Compilers most of us use today (gcc / mingw, clang, Visual Studio, ICC) are
all C++ capable. To build current versions of gcc, you even need a C++98
compatible compiler. For CLang, a C++11 capable one. So platforms that aren't
legacy have all a C++ compiler available. And I believe people that will be
ready to adopt proj 6 are unlikely to do so on legacy systems where no C++
compiler would be available.

Regarding which C++ flavour, I'd like to push for C++11. It brings upon C++98
a number of useful features. A few that come to mind for the work to come
would be the override keyword (to make sure virtual functions are properly
deriving from their base defintions), std::unique_ptr (to simplify memory
management).
C++11 means gcc >= 4.8, clang >= 3.3 and Visual Studio >= 2015.
We switched to C++11 requirement for GDAL for the latest GDAL 2.3.0 version,
and up to now, I haven't heard strong complaints related to that.

As the functional scope of PROJ is extended (historically proj was a
'projection calculator', which was enriched with early-binding datum
transformation capabilities, reworked with all the new PROJ 5 capabilities
paving the road for late-binding capabilities, and, with the planned work,
becoming a kind of 'libcrs'), it seems natural to use the appropriate tools to
implement those enhanced capabilities.

I think allowing C++ could be an opportunity to modernize other parts of the
existing code base: like the implementation of transformations/projections as
C++ objects instead of the current function pointer approach. But that's a bit
beyond my current objectives. Just wanted to mention this as an opportunity.

Thoughts ?

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Jürgen E. Fischer
Hi Even,

On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:
> I know that this choice of C++ could be perceived as an obstacle for
> portability of PROJ, but I don't think this is an actual concern in practice.

Internally, but with a (alternative?) C-API to the outside?   Or also C++ as
the (only) external interface?


Jürgen

--
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden             http://www.norbit.de

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Even Rouault-2
On mercredi 23 mai 2018 13:50:53 CEST Jürgen E. Fischer wrote:
> Hi Even,
>
> On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:
> > I know that this choice of C++ could be perceived as an obstacle for
> > portability of PROJ, but I don't think this is an actual concern in
> > practice.

> Internally, but with a (alternative?) C-API to the outside?  
> Or also C++ as
> the (only) external interface?

OK let me try to summarize my thoughts in a bullet list fashion :-)
- C++ as mostly for internal use for new code to be added, related to CRS
modelling and WKT managment
- Part of that C++ code as possibly externally accessible
- Part of that C++ externally accessible API might also be exposed through new
C API
- existing proj C API still available through the plans exposed in the past.

The first 3 bullets are quite similar to how GDAL handles things.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Kurt Schwehr-2
+1 from me as a user and minor contributor

Having C++ internally would allow for some nice cleanups especially with C++11 and unique_ptr.

On Wed, May 23, 2018 at 5:05 AM, Even Rouault <[hidden email]> wrote:
On mercredi 23 mai 2018 13:50:53 CEST Jürgen E. Fischer wrote:
> Hi Even,
>
> On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:
> > I know that this choice of C++ could be perceived as an obstacle for
> > portability of PROJ, but I don't think this is an actual concern in
> > practice.

> Internally, but with a (alternative?) C-API to the outside? 
> Or also C++ as
> the (only) external interface?

OK let me try to summarize my thoughts in a bullet list fashion :-)
- C++ as mostly for internal use for new code to be added, related to CRS
modelling and WKT managment
- Part of that C++ code as possibly externally accessible
- Part of that C++ externally accessible API might also be exposed through new
C API
- existing proj C API still available through the plans exposed in the past.

The first 3 bullets are quite similar to how GDAL handles things.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Mateusz Loskot
On 23 May 2018 at 18:04, Kurt Schwehr <[hidden email]> wrote:
> +1 from me as a user and minor contributor
>
> Having C++ internally would allow for some nice cleanups especially with
> C++11 and unique_ptr.

I second that from similar position.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Thomas Knudsen
In reply to this post by Even Rouault-2
> OK let me try to summarize my thoughts in a bullet list fashion

... misread that as "thoughts in a bullshit fashion" :-)

Although I will probably never grow up to actually *love* C++,
I occasionally fall in love with the "the much smaller and cleaner
language struggling to get out" (as C++ creator Bjarne Stroustrup
stated it) .

I do, however, *love* the thought of seeing libproj supporting
WKT2, ISO19111 and friends. And if embracing C++ is the way
you can implement that fastest and most efficiently, I believe that
is what should be done.

I have spent 2 years of my life working towards a libproj more
suitable for handling general geodetic transformations, while
staying within the bounds set by C89. This really makes me want
to see a less restrictive environment for your important next step.

Also, I would love to see a more clearly defined delineation of
where PROJ stops and GDAL takes over. Obviously, this will
only happen by applying an overall architectural restructuring,
involving both C and C++ code, from both PROJ and GDAL.

I believe, as accuracy expectations grow, PROJ will have to
evolve into not only a libcrs, but into a lib-general-geodesy,
to stay relevant. Doing that without introducing sharper tools
will result in an unmaintainable mess.

So enough of my "thoughts in bullshit fashion" - just let me
summarize by saying that I believe that introducing C++
elements in libproj will be necessary to achieve the goals
set forward in the gdal barn raising, and hence not really a
decision to consider, but just an inevitable bullet to bite
(or candy to enjoy, for those so inclined).




2018-05-23 14:05 GMT+02:00 Even Rouault <[hidden email]>:
On mercredi 23 mai 2018 13:50:53 CEST Jürgen E. Fischer wrote:
> Hi Even,
>
> On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:
> > I know that this choice of C++ could be perceived as an obstacle for
> > portability of PROJ, but I don't think this is an actual concern in
> > practice.

> Internally, but with a (alternative?) C-API to the outside? 
> Or also C++ as
> the (only) external interface?

OK let me try to summarize my thoughts in a bullet list fashion :-)
- C++ as mostly for internal use for new code to be added, related to CRS
modelling and WKT managment
- Part of that C++ code as possibly externally accessible
- Part of that C++ externally accessible API might also be exposed through new
C API
- existing proj C API still available through the plans exposed in the past.

The first 3 bullets are quite similar to how GDAL handles things.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

andrew.bell.ia@gmail.com

If C++ isn't used at the API, isn't this an implementation detail as long as it builds on systems you want to target?

That said, the issue I have with the GDAL API, which is mentioned as a model, is that it's complicated in that it's always unclear who owns what and what needs to be freed by the application, etc.  It creates bugs and ambiguities.  Whether the API is C or C++, allowing the library to manage data to the extent possible is desirable.  Looking at the proj 4 API, there are only a few instances where you might need to look at the source code or documentation on this (proj_list..., a few calls that take non-const char * and a few that take char **), so not a bad starting point.  If C++ allows a cleaner interface, I'd be a happy user, but if the same effect can be achieved with C, that's fine as well.  If a binary-compatible C++ interface is important, hiding the implementation behind a pointer is standard practice and works pretty well.

On Wed, May 23, 2018 at 1:11 PM, Thomas Knudsen <[hidden email]> wrote:
> OK let me try to summarize my thoughts in a bullet list fashion

... misread that as "thoughts in a bullshit fashion" :-)

Although I will probably never grow up to actually *love* C++,
I occasionally fall in love with the "the much smaller and cleaner
language struggling to get out" (as C++ creator Bjarne Stroustrup
stated it) .

I do, however, *love* the thought of seeing libproj supporting
WKT2, ISO19111 and friends. And if embracing C++ is the way
you can implement that fastest and most efficiently, I believe that
is what should be done.

I have spent 2 years of my life working towards a libproj more
suitable for handling general geodetic transformations, while
staying within the bounds set by C89. This really makes me want
to see a less restrictive environment for your important next step.

Also, I would love to see a more clearly defined delineation of
where PROJ stops and GDAL takes over. Obviously, this will
only happen by applying an overall architectural restructuring,
involving both C and C++ code, from both PROJ and GDAL.

I believe, as accuracy expectations grow, PROJ will have to
evolve into not only a libcrs, but into a lib-general-geodesy,
to stay relevant. Doing that without introducing sharper tools
will result in an unmaintainable mess.

So enough of my "thoughts in bullshit fashion" - just let me
summarize by saying that I believe that introducing C++
elements in libproj will be necessary to achieve the goals
set forward in the gdal barn raising, and hence not really a
decision to consider, but just an inevitable bullet to bite
(or candy to enjoy, for those so inclined).




2018-05-23 14:05 GMT+02:00 Even Rouault <[hidden email]>:
On mercredi 23 mai 2018 13:50:53 CEST Jürgen E. Fischer wrote:
> Hi Even,
>
> On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:
> > I know that this choice of C++ could be perceived as an obstacle for
> > portability of PROJ, but I don't think this is an actual concern in
> > practice.

> Internally, but with a (alternative?) C-API to the outside? 
> Or also C++ as
> the (only) external interface?

OK let me try to summarize my thoughts in a bullet list fashion :-)
- C++ as mostly for internal use for new code to be added, related to CRS
modelling and WKT managment
- Part of that C++ code as possibly externally accessible
- Part of that C++ externally accessible API might also be exposed through new
C API
- existing proj C API still available through the plans exposed in the past.

The first 3 bullets are quite similar to how GDAL handles things.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Andrew Bell
[hidden email]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Even Rouault-2
Andrew,

> If C++ isn't used at the API, isn't this an implementation detail as long
> as it builds on systems you want to target?

Indeed, but that's already an important requirement with respect to the
current situation.

As I mentionned, I think some of the C++ code might be useful as being used
directly as API. What exactly remains to be determined. After some
prototyping, I'll have a better vision.

>
> That said, the issue I have with the GDAL API, which is mentioned as a
> model,

I didn't mean GDAL as a model for the API. Just that some code of it might be
reused as a starting point.

> is that it's complicated in that it's always unclear who owns what
> and what needs to be freed by the application, etc.  

That's another point, but I'd hope the GDAL API doc to be generally clear on
ownership and what destroy functions should be called. If not, ticket or pull
requests are welcome. And the API surface of GDAL is much larger than proj, so
hard to compare.

> If a binary-compatible C++ interface
> is important, hiding the implementation behind a pointer is standard
> practice and works pretty well.

I wouldn't aim for a binary-compatible C++ ABI between major versions of the
library where new functionality might be added. That's just impossible/too
complicated to achieve in practice: even if you hide private members (which
might be a good idea to be able to deal with bugs in minor versions), any new
virtual method breaks the C++ ABI for example.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Mateusz Loskot
In reply to this post by andrew.bell.ia@gmail.com
On 23 May 2018 at 19:59, Andrew Bell <[hidden email]> wrote:
> That said, the issue I have with the GDAL API, which is mentioned as a
> model, is that it's complicated in that it's always unclear who owns what
> and what needs to be freed by the application, etc.  It creates bugs and
> ambiguities.  Whether the API is C or C++, allowing the library to manage
> data to the extent possible is desirable.  Looking at the proj 4 API, there
> are only a few instances where you might need to look at the source code or
> documentation on this (proj_list..., a few calls that take non-const char *
> and a few that take char **), so not a bad starting point.

Since the discussion touches the aspect if/how choice of C++ affects API
discoverability and transparency [1], I'd only point out that costness of
pointer/pointee does not necessarily indicate ownership responsibility.

All three are perfectly delete/free-able:

char const* f1() { return new char{'\a'}; }
char* const f2() { return new char{'\a'}; }
char const* const f3() { return new char{'\a'}; }

Although I'm mostly C++11+ user, I agree with Andrew clean OOP interface
can be achieved using both, C or C++.
(GTK always served me as an excellent example of clean OOP in C.)

Finally, if Even's choice is C++, I'm fairly certain Even will not go
for equivalent
of GDAL's CPL strings, lists, etc. jugglers, but stick to C++ standard library.

[1] https://accu.org/index.php/journals/1572

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

support-2
In reply to this post by Even Rouault-2
Hello,

I think that if you want to keep proj. downwards compatible with C (and
C++) then you should keep it standard C. If you use c++ in the library
NOT any "just C" compiler can ever compile it. So as proj. is so small
library I would keep it standard c since nobody really cares if it is c
or c++ - and anybody can write it to c++ or whatever in very small time
- that is not a problem.

So to be able to use proj. in as many targets as possible, also in
smaller devices like hand held devices or so ... I would strongly
recommend to keep it standard c for ever! - But when that is now said
... they most likely do everything else but what is wanted!? haha! (y)

Janne.

-------------------------------

Even Rouault kirjoitti 2018-05-23 13:25:
> Hi,
>
> As announced previously, and given that the SQLite related thread has
> calmed
> down (except license related discussions that aren't directly related
> to it),
> this is the second potentially controversial topic I wanted to discuss.
> .....
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Kurt Schwehr-2
Janne,

Can you give specific examples of these platforms that only support C that you think PROJ should be supporting?

On Wed, May 23, 2018 at 9:51 PM, <[hidden email]> wrote:
Hello,

I think that if you want to keep proj. downwards compatible with C (and
C++) then you should keep it standard C. If you use c++ in the library
NOT any "just C" compiler can ever compile it. So as proj. is so small
library I would keep it standard c since nobody really cares if it is c
or c++ - and anybody can write it to c++ or whatever in very small time
- that is not a problem.

So to be able to use proj. in as many targets as possible, also in
smaller devices like hand held devices or so ... I would strongly
recommend to keep it standard c for ever! - But when that is now said
... they most likely do everything else but what is wanted!? haha! (y)

Janne.

-------------------------------

Even Rouault kirjoitti 2018-05-23 13:25:
> Hi,
>
> As announced previously, and given that the SQLite related thread has
> calmed
> down (except license related discussions that aren't directly related
> to it),
> this is the second potentially controversial topic I wanted to discuss.
> .....
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

support-2

Hello,


there are very many platforms at the lower level MCU's which mainly use standard c and avoid using c++ ... just to keep it simple and easy! - I don't want to start listing them here ... they are just too many .. all MCU's usually have assembler or c programming environment but seldom c++ is used or either easy available.


Transition to c++ would just add problems later! I have been programming c++ since 1995 and I still find it as a rather stupid platform that just adds problems - to switch back to lower level if required for example - At the moment I would rather hang the guy who invented the whole problem (c++) at the first place! All it usually does, it makes programs harder to follow and read and especially to port to lower level targets .. which is often required and desired in real World projects.

Janne.

-----------------------------------------------

Kurt Schwehr kirjoitti 2018-05-24 08:04:

Janne,
 
Can you give specific examples of these platforms that only support C that you think PROJ should be supporting?

On Wed, May 23, 2018 at 9:51 PM, <[hidden email]> wrote:
Hello,

I think that if you want to keep proj. downwards compatible with C (and
C++) then you should keep it standard C. If you use c++ in the library
NOT any "just C" compiler can ever compile it. So as proj. is so small
library I would keep it standard c since nobody really cares if it is c
or c++ - and anybody can write it to c++ or whatever in very small time
- that is not a problem.

So to be able to use proj. in as many targets as possible, also in
smaller devices like hand held devices or so ... I would strongly
recommend to keep it standard c for ever! - But when that is now said
... they most likely do everything else but what is wanted!? haha! (y)

Janne.

-------------------------------

Even Rouault kirjoitti 2018-05-23 13:25:
> Hi,
>
> As announced previously, and given that the SQLite related thread has
> calmed
> down (except license related discussions that aren't directly related
> to it),
> this is the second potentially controversial topic I wanted to discuss.
> .....
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


 
--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Kristian Evers-2
Janne,

Your argument isn’t very strong without at least mentioning a few specific cases where C++ is not available. I have previously looked into this area and from what I could understand at the time it is mostly a myth that you can’t use C++ on embedded systems. Please elaborate so we can make an enlightened decision.

/Kristian

On 24 May 2018, at 08:10, [hidden email] wrote:

Hello,


there are very many platforms at the lower level MCU's which mainly use standard c and avoid using c++ ... just to keep it simple and easy! - I don't want to start listing them here ... they are just too many .. all MCU's usually have assembler or c programming environment but seldom c++ is used or either easy available

Transition to c++ would just add problems later! I have been programming c++ since 1995 and I still find it as a rather stupid platform that just adds problems - to switch back to lower level if required for example - At the moment I would rather hang the guy who invented the whole problem (c++) at the first place! All it usually does, it makes programs harder to follow and read and especially to port to lower level targets .. which is often required and desired in real World projects.

Janne.

-----------------------------------------------

Kurt Schwehr kirjoitti 2018-05-24 08:04:

Janne,
 
Can you give specific examples of these platforms that only support C that you think PROJ should be supporting?

On Wed, May 23, 2018 at 9:51 PM, <[hidden email]> wrote:
Hello,

I think that if you want to keep proj. downwards compatible with C (and
C++) then you should keep it standard C. If you use c++ in the library
NOT any "just C" compiler can ever compile it. So as proj. is so small
library I would keep it standard c since nobody really cares if it is c
or c++ - and anybody can write it to c++ or whatever in very small time
- that is not a problem.

So to be able to use proj. in as many targets as possible, also in
smaller devices like hand held devices or so ... I would strongly
recommend to keep it standard c for ever! - But when that is now said
... they most likely do everything else but what is wanted!? haha! (y)

Janne.

-------------------------------

Even Rouault kirjoitti 2018-05-23 13:25:
> Hi,
>
> As announced previously, and given that the SQLite related thread has
> calmed
> down (except license related discussions that aren't directly related
> to it),
> this is the second potentially controversial topic I wanted to discuss.
> .....
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


 
--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Kurt Schwehr-2
In reply to this post by support-2
Janne,

You mean microcontroller? https://en.wikipedia.org/wiki/MCU

How about naming just one example that you think proj must support?  

Make some sort of useful concrete statement.

However, you do appreciate you making me laugh with your C++ comments trying to troll.


On Wed, May 23, 2018 at 11:10 PM, <[hidden email]> wrote:

Hello,


there are very many platforms at the lower level MCU's which mainly use standard c and avoid using c++ ... just to keep it simple and easy! - I don't want to start listing them here ... they are just too many .. all MCU's usually have assembler or c programming environment but seldom c++ is used or either easy available.


Transition to c++ would just add problems later! I have been programming c++ since 1995 and I still find it as a rather stupid platform that just adds problems - to switch back to lower level if required for example - At the moment I would rather hang the guy who invented the whole problem (c++) at the first place! All it usually does, it makes programs harder to follow and read and especially to port to lower level targets .. which is often required and desired in real World projects.

Janne.

-----------------------------------------------

Kurt Schwehr kirjoitti 2018-05-24 08:04:

Janne,
 
Can you give specific examples of these platforms that only support C that you think PROJ should be supporting?

On Wed, May 23, 2018 at 9:51 PM, <[hidden email]> wrote:
Hello,

I think that if you want to keep proj. downwards compatible with C (and
C++) then you should keep it standard C. If you use c++ in the library
NOT any "just C" compiler can ever compile it. So as proj. is so small
library I would keep it standard c since nobody really cares if it is c
or c++ - and anybody can write it to c++ or whatever in very small time
- that is not a problem.

So to be able to use proj. in as many targets as possible, also in
smaller devices like hand held devices or so ... I would strongly
recommend to keep it standard c for ever! - But when that is now said
... they most likely do everything else but what is wanted!? haha! (y)

Janne.

-------------------------------

Even Rouault kirjoitti 2018-05-23 13:25:
> Hi,
>
> As announced previously, and given that the SQLite related thread has
> calmed
> down (except license related discussions that aren't directly related
> to it),
> this is the second potentially controversial topic I wanted to discuss.
> .....
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


 
--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Heiko Klein-3
In reply to this post by Mateusz Loskot
Hei,

C++ as internal language is no problem for me. But when it turns to API,
C-objects and C++ objects usually don't work together, even things as
simple as strings are incompatible, so integration with other languages
(python,R,java and others) only works by using a C++->C wrapper. These
wrappers exist, but create an additional burden. If possible, I wouldn't
like to see any C++ code exposed.

Heiko

On 2018-05-23 20:30, Mateusz Loskot wrote:

> On 23 May 2018 at 19:59, Andrew Bell <[hidden email]> wrote:
>> That said, the issue I have with the GDAL API, which is mentioned as a
>> model, is that it's complicated in that it's always unclear who owns what
>> and what needs to be freed by the application, etc.  It creates bugs and
>> ambiguities.  Whether the API is C or C++, allowing the library to manage
>> data to the extent possible is desirable.  Looking at the proj 4 API, there
>> are only a few instances where you might need to look at the source code or
>> documentation on this (proj_list..., a few calls that take non-const char *
>> and a few that take char **), so not a bad starting point.
>
> Since the discussion touches the aspect if/how choice of C++ affects API
> discoverability and transparency [1], I'd only point out that costness of
> pointer/pointee does not necessarily indicate ownership responsibility.
>
> All three are perfectly delete/free-able:
>
> char const* f1() { return new char{'\a'}; }
> char* const f2() { return new char{'\a'}; }
> char const* const f3() { return new char{'\a'}; }
>
> Although I'm mostly C++11+ user, I agree with Andrew clean OOP interface
> can be achieved using both, C or C++.
> (GTK always served me as an excellent example of clean OOP in C.)
>
> Finally, if Even's choice is C++, I'm fairly certain Even will not go
> for equivalent
> of GDAL's CPL strings, lists, etc. jugglers, but stick to C++ standard library.
>
> [1] https://accu.org/index.php/journals/1572
>
> Best regards,
>

--
Dr. Heiko Klein                   Norwegian Meteorological Institute
Tel. + 47 22 96 32 58             P.O. Box 43 Blindern
http://www.met.no                 0313 Oslo NORWAY
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Kristian Evers-2
In reply to this post by Even Rouault-2
Figured I’d chime in on this subject as well. As one of the co-signers of gdalbarn.com
I am obviously on board with the switch to include the use of C++ in PROJ. And from
the responses so far it seems the community is largely behind the effort as well,
apart from a few skeptics. I agree that the inclusion of C++ in the project is not as
“dangerous" as it might initially sound like. The only real issue that’s been highlighted
so far is complications with compilation on microcontrollers but those claims still haven’t
been backed up by real world examples, so I would say we are good to go on this.

Like Thomas, I am not particularly well-versed in C++ so I am not one to talk about
best practices. For this reason I would ask that some of the C++ experts in the
community come up with a set of coding guidelines for the C++ parts of the code
base. Lately the lack of code formatting conventions in PROJ has been frustrating
to several contributors. With the addition of the new C++ parts of the code we have
the chance to at least include conventions for the C++ code. I know this has been
a topic for GDAL recently and since we have a big overlap with the GDAL community
perhaps we can benefit from their experiences. Kurt and Even, I believe you’ve been
involved in improving the GDAL code formatting rules, would one of you be willing to
suggest something that we can use in PROJ? A good starting point, I guess, would

I know this is poking the hornets nest and there’s a risk that my request can result in
yet another heated discussion about code style. Please keep the discussion civil
and keep in mind that this is meant as a preemptive strike to avoid future flame
wars.

/Kristian

On 23 May 2018, at 12:25, Even Rouault <[hidden email]> wrote:

Hi,

As announced previously, and given that the SQLite related thread has calmed
down (except license related discussions that aren't directly related to it),
this is the second potentially controversial topic I wanted to discuss.

To be able to handle WKT v1 and WKT v2, relying on the
object modeling of CRS, coordinate transformations and related concepts,
detailed in the ISO 19111:2018 / OGC 18-005r1 "OGC Abstract Specification:
Topic 2: Referencing by coordinates" seems an appropriate start.
See http://www.opengeospatial.org/standards/requests/166 (note: access to the
draft docx requires OGC membership currently)

ISO 19111:2018 will soon replace the current ISO 19111:2007 / OGC 08-015r2 :
http://portal.opengeospatial.org/files/?artifact_id=39049

This updated specification brings new concepts, particularly the
concept of dynamic geodetic reference frames (dynamic datums) that are going
to be fundamental for current (ITRF, WGS84) or future datums (NATRF2022 that
will replace NAD83 in the USA, ATRF in Australia ...)
In the coming months, there will be revision of WKT 2 to catch up with this
evolution of ISO 19111.
Future versions of the EPSG database will also later adapt to this.
ISO 19111 exposes the concepts with UML modelling. We also have GeoAPI
( http://www.opengeospatial.org/standards/geoapi ) that
offers Java (and in progress Python) class hierarchies. In the PROJ context,
it seems natural to opt for C++. Part of that new API will be exposed to C ,
the exact scope remains to be determined depending on the needs. To be clear,
this would not impact the status of existing proj C API, and the already
announced retirement plans of projects.h and proj_api.h.

On a more practical note, this is also the opportunity to reuse existing C++
code from GDAL (WKT tree node building).

I know that this choice of C++ could be perceived as an obstacle for
portability of PROJ, but I don't think this is an actual concern in practice.
Compilers most of us use today (gcc / mingw, clang, Visual Studio, ICC) are
all C++ capable. To build current versions of gcc, you even need a C++98
compatible compiler. For CLang, a C++11 capable one. So platforms that aren't
legacy have all a C++ compiler available. And I believe people that will be
ready to adopt proj 6 are unlikely to do so on legacy systems where no C++
compiler would be available.

Regarding which C++ flavour, I'd like to push for C++11. It brings upon C++98
a number of useful features. A few that come to mind for the work to come
would be the override keyword (to make sure virtual functions are properly
deriving from their base defintions), std::unique_ptr (to simplify memory
management).
C++11 means gcc >= 4.8, clang >= 3.3 and Visual Studio >= 2015.
We switched to C++11 requirement for GDAL for the latest GDAL 2.3.0 version,
and up to now, I haven't heard strong complaints related to that.

As the functional scope of PROJ is extended (historically proj was a
'projection calculator', which was enriched with early-binding datum
transformation capabilities, reworked with all the new PROJ 5 capabilities
paving the road for late-binding capabilities, and, with the planned work,
becoming a kind of 'libcrs'), it seems natural to use the appropriate tools to
implement those enhanced capabilities.

I think allowing C++ could be an opportunity to modernize other parts of the
existing code base: like the implementation of transformations/projections as
C++ objects instead of the current function pointer approach. But that's a bit
beyond my current objectives. Just wanted to mention this as an opportunity.

Thoughts ?

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

C++ formatting rules [was Re: Use of C++]

Even Rouault-2
> For this reason I would ask that some of the
> C++ experts in the community come up with a set of coding guidelines for
> the C++ parts of the code base. Lately the lack of code formatting
> conventions in PROJ has been frustrating to several contributors. With the
> addition of the new C++ parts of the code we have the chance to at least
> include conventions for the C++ code. I know this has been a topic for GDAL
> recently and since we have a big overlap with the GDAL community perhaps we
> can benefit from their experiences. Kurt and Even, I believe you’ve been
> involved in improving the GDAL code formatting rules, would one of you be
> willing to suggest something that we can use in PROJ? A good starting
> point, I guess, would be
> https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting.
>

One possibility would be to claim "this project has no particular C++ code
formating rules. Do reasonable things [1]". But I'm afraid that won't be
enough.

I've experimented a bit with the suggested clang-format. Basically why not
just using it in its default setup (LLVM style), without a particular .clang-
format ?

And have a scripts/autoformat.sh [2], to autoreformat things. Travis-CI could
run it, and bail out if a file has been reformatted.

Equivalently to my above adhoc script, I also see there is a 'git clang-
format' tool that automatically runs clang-format on files that have been git
added. Actually when testing it it seems to run it only on the parts you
changed, probably to avoid causing code churn in non-modified parts: cf
https://electronjs.org/docs/development/clang-format

That said there might be a slight risk of output instability depending on the
clang-format version. I've tried with the one of LLVM 3.7, 3.8 and 7dev
The good news is that the output of 3.8 and 7dev is identical on the .cpp
files I've sketched.

There was a difference with 3.7 and later versions regarding include sorting
header (with 3.7, in foo.cpp, include "foo.h" must come first, whereas later
versions insist on includes being sorted, accepting as an exception that
"foo.h" is first, probably for compat with 3.7...). But 3.7 can probably be
considered ancient, so let's aim for >= 3.8

Even

[1] Reminds me of road signs in Montana "Drive at reasonable speed"...

[2]

#!/bin/sh
set -eu
clang-format $1 > $1.reformatted
if diff -u $1.reformatted $1; then
    # No reformatting: remove temporary file
    rm $1.reformatted
else
    # Differences. Backup original file, and use reformatted file
    cp $1 $1.before_reformat
    mv $1.reformatted $1
fi



--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: C++ formatting rules [was Re: Use of C++]

Kurt Schwehr-2
+1 to Even's suggestion.

The default is the least complicated setup.  And you can always turn off formatting for small blocks that really need special formatting.  E.g.  a matrix


On Sun, May 27, 2018, 6:45 AM Even Rouault <[hidden email]> wrote:
> For this reason I would ask that some of the
> C++ experts in the community come up with a set of coding guidelines for
> the C++ parts of the code base. Lately the lack of code formatting
> conventions in PROJ has been frustrating to several contributors. With the
> addition of the new C++ parts of the code we have the chance to at least
> include conventions for the C++ code. I know this has been a topic for GDAL
> recently and since we have a big overlap with the GDAL community perhaps we
> can benefit from their experiences. Kurt and Even, I believe you’ve been
> involved in improving the GDAL code formatting rules, would one of you be
> willing to suggest something that we can use in PROJ? A good starting
> point, I guess, would be
> https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting.
>

One possibility would be to claim "this project has no particular C++ code
formating rules. Do reasonable things [1]". But I'm afraid that won't be
enough.

I've experimented a bit with the suggested clang-format. Basically why not
just using it in its default setup (LLVM style), without a particular .clang-
format ?

And have a scripts/autoformat.sh [2], to autoreformat things. Travis-CI could
run it, and bail out if a file has been reformatted.

Equivalently to my above adhoc script, I also see there is a 'git clang-
format' tool that automatically runs clang-format on files that have been git
added. Actually when testing it it seems to run it only on the parts you
changed, probably to avoid causing code churn in non-modified parts: cf
https://electronjs.org/docs/development/clang-format

That said there might be a slight risk of output instability depending on the
clang-format version. I've tried with the one of LLVM 3.7, 3.8 and 7dev
The good news is that the output of 3.8 and 7dev is identical on the .cpp
files I've sketched.

There was a difference with 3.7 and later versions regarding include sorting
header (with 3.7, in foo.cpp, include "foo.h" must come first, whereas later
versions insist on includes being sorted, accepting as an exception that
"foo.h" is first, probably for compat with 3.7...). But 3.7 can probably be
considered ancient, so let's aim for >= 3.8

Even

[1] Reminds me of road signs in Montana "Drive at reasonable speed"...

[2]

#!/bin/sh
set -eu
clang-format $1 > $1.reformatted
if diff -u $1.reformatted $1; then
    # No reformatting: remove temporary file
    rm $1.reformatted
else
    # Differences. Backup original file, and use reformatted file
    cp $1 $1.before_reformat
    mv $1.reformatted $1
fi



--
Spatialys - Geospatial professional services
http://www.spatialys.com

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

J Luis
In reply to this post by Kristian Evers-2


On Sun, May 27, 2018 at 10:32 AM, Kristian Evers <[hidden email]> wrote:
Figured I’d chime in on this subject as well. As one of the co-signers of gdalbarn.com
I am obviously on board with the switch to include the use of C++ in PROJ. And from
the responses so far it seems the community is largely behind the effort as well,
apart from a few skeptics.

Hi,

I am sorry but I don't think we can conclude that. The proponents naturally are in favor and, given that they will do the work, that is a strong argument. However, there is often forgotten price to pay when a code moves from C to C++ that is the reduction of potential contributors. Speaking only from myself, but knowing I'm not alone, C++ is an awfully complicated language that is beyond my suffering endurance. Not that it was really important but there were times I tried to contribute to GDAL but hit the C++ wall. 

I also find the embedded systems argument a valid one but have poor knowledge on the subject. What I have read here and there is that C++ codes makes bigger and more resource demanding needs that those made with C.

That said, and as I mentioned in beginning, those that will implement the new features have ofc the main word.

P.S. Sorry, couldn't resist to point to this provocative reading.

Joaquim Luis

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of C++

Kurt Schwehr-2
I encourage anyone with a real microcontroller example that needs Proj but can't use C++ to step forward.

I also encourage people to provide example of real trouble along the lines of Bucher's to provide examples.  Especially powerful if done up in https://godbolt.org/ or similar.  I argue that C++ can do anything as well as C can.  Just like any language, it also has plenty of ways to build junk.

Please do not use GDAL as the C++ standard... Most of GDAL is legacy style C++ by today's standards. 

If people are having problems with a C++ language feature that is proposed for use, it would be good to discuss it.  e.g.


On Sun, May 27, 2018 at 11:09 AM, J Luis <[hidden email]> wrote:


On Sun, May 27, 2018 at 10:32 AM, Kristian Evers <[hidden email]> wrote:
Figured I’d chime in on this subject as well. As one of the co-signers of gdalbarn.com
I am obviously on board with the switch to include the use of C++ in PROJ. And from
the responses so far it seems the community is largely behind the effort as well,
apart from a few skeptics.

Hi,

I am sorry but I don't think we can conclude that. The proponents naturally are in favor and, given that they will do the work, that is a strong argument. However, there is often forgotten price to pay when a code moves from C to C++ that is the reduction of potential contributors. Speaking only from myself, but knowing I'm not alone, C++ is an awfully complicated language that is beyond my suffering endurance. Not that it was really important but there were times I tried to contribute to GDAL but hit the C++ wall. 

I also find the embedded systems argument a valid one but have poor knowledge on the subject. What I have read here and there is that C++ codes makes bigger and more resource demanding needs that those made with C.

That said, and as I mentioned in beginning, those that will implement the new features have ofc the main word.

P.S. Sorry, couldn't resist to point to this provocative reading.

Joaquim Luis

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
12