First of all I am a 90% windows developer, so I'm well aware of the 
sensitivities of windows.  Guess who builds the EDB Windows PostGIS package? – 

I do admit I don't use C++ much so perhaps I don't fully understood the gripe 
that C++ API developers are complaining about.


That said what are we arguing about here?


We are talking about developers who want to use the C++ API adding an extra 
line in their script to make their intentions clear.

By making your intentions clear – you know others who want to use the C++API 
will be required to do so too.  Which means you most likely intend to run in a 
statically compiled or sandboxed environment as all have described that affects 
no one but users of your project (presumably users who are quite capable of 
compiling their own stuff) or YOU, who take on the responsibility of packaging 
as does SAFE Software and other companies.


First let me define what I mean by Public:  Projects that rely on packagers to 
distribute the artifacts of their project.


Everyone I talk to that is a C++ developer – I hear "But you are saying C++ API 
is not as important as the  C-API  and you are discouraging use of the  C++ API 
by calling it unstable."


What I'm saying is -  "C++ API is not AS stable (and probably be even less 
stable as we introduce new  C++ features) . Sure it's important but we want to 
change it. The C-API is the bulk of what most public projects using GEOS are 
using.  I think after osm2pgsql left, there are no more public projects using 
the C++ API. 


If more public projects were already using the C++ API I would have a different 
tune, but we don't so we are in a good position to enforce it before it's too 

Thus I care more about ensuring that projects that eventually require packager 
support use the C-API (at least for now)  than I care about your frustration of 
having to add an extra line to your compile scripts"


> Because of complexity - something GEOS has an advantage. GEOS should not be 
> used or turned into as Expert only library

Exactly and if we continue appealing to every C++ API developer gimme  "But 
it's a C++ API", we'll become just as complex as Boost Geometry in no time.


At this point GEOS as a C-API is more important to the general consumer than 
its use as a C++ API, and if C++ developers continue with this attitude of  "I 
don't care if it has a stable C++ API, cause I can stick with the old version 
if it changes too much and I compile my own stuff anyway", then the C++ API 
will always have an UNSTABLE caveat.  We don't even guarantee the C++ API won't 
change in a micro (though we try not to do that).






From: geos-devel [] On Behalf Of 
Sent: Saturday, May 18, 2019 2:44 AM
To: GEOS Development List <>
Subject: Re: [geos-devel] RFC 9: Restore C++ API as public API


For the second time, this discussion has become very passionate at some point. 
That being said, I believe all the package management issues being used as an 
excuse are more of an issue for Linux-based systems. Those who develop 
Linux-based applications should know better if they depend on system wide 
library distribution for their dependencies via some package management. For 
them, they should have stability in mind when doing their development. Why 
should a larger community pay for the poor choice of others and would have to 
jump through additional hoops to achieve what should be trivial in C++? I am 
not a Linux expert/developer and would not be in a position to judge. Such 
applications could consider static linking as alternative or risk being dropped 
by the PACKAGE MANAGERS and those who want to make their work easier. It is the 
responsibility of statically linked application to fix security updates. I do 
acknowledge most of the PSC/maintainers primary OS might be linux and might 
have their own preferences/biases.  


GEOS, we should not forget has a considerable number of Windows users and on 
windows, each application is responsible for its own "sandbox" environment. A 
case in point is the layout of Postgis windows distribution as an example. If 
there is a required security update, it is handled at the individually 
installed application level and not system wide. People develop their own 
schemes to realize how their dependencies are met. I rarely hear such issues on 
Windows like package management. GEOS has the ability to gain more traction if 
such artificial restrictions are removed.


Desktop application development stands to benefit a lot on windows - yes there 
are people out there using the library on windows. There is no gainsaying that 
those doing server application have other considerations to keep in mind. There 
should be nothing like "end of discussion - done" rather it should be based on 
facts/guidelines/practices as they are. Those who break it should pay the 
price. That said what, why should we prevent the C++ API for being used? Yes, 
it has special needs. I do not hear such arguments with GDAL. They broke the 
API and people had to fix their stuff did in order to use newer releases. The 
ABI issues as document should just be used as reference for those who complain. 
After all, GEOS is not LINUX kernel where such drastic considerations have 
their merits. Even LINUX, we have seen some positive transformations in the way 
Linux kernel is managed.


Some people use mostly C language for the obvious reasons. Others use C++ and 
are looking forward to use the high level abstractions the new standards (11, 
14, 17, 20x) are providing. The interests of the minority should be respected 
but should not be used as an excuse to stifle innovation. Yes there is Boost 
Geometry as an alternative but why has it not gained traction? Because of 
complexity - something GEOS has a an advantage. GEOS should not be used or 
turned into as Expert only library. Please remember package management is a 
long standing issue in C/C++ based on its characteristics - those being the 
same that make them popular when people want primarily performance.


On Sat, May 18, 2019 at 12:23 AM Regina Obe < 
<> > wrote:


I think you misunderstood me a little

> The first and third statements in the second paragraph of your response is 
> false. 
> I have ever asked to "guarantee a stable C++ API at this point in time" or at 
> any point ever.
> It's a fact.
> [Regina Obe] 

I never said you wanted to guarantee a stable C++ API.  And we don't have one 
is my point.
Something that is unstable should not be shared.  It should be statically 
linked or set aside for your own project and as such you shouldn't expect 
package maintainers to carry your project.  

> The second statement in the second paragraph of your response is also false.
> GEOS users can and do depend on the C++ API.
> It's a fact. 
No disagreement there - just don't want packagers burdened with having to ship 
these projects and right now we have few if any that use the C++ API
that packagers need to ship.  I'd like to keep it that way by discouraging 
sharing of the C++ API.  Installing headers etc -- as pramsey suggested would 
just open up the flood-gates of C++ projects relying on the C++-API until we 
have some REALLY IMPORTANT C++ project that relies on GEOS that packagers would 
like to ship, and expecting them to statically link every GEOS use is insane 
and a security hole.

I care more about packagers feeling comfortable about shipping a newer GEOS 
C-API and PostGIS being able to use a newer GEOS C-API than I feel about making 
C++ developers happy. You people have all proven to be only concerned about 
your self-interest and your toys.

> The arguments you present show to me you're pursuing goals of a package 
> manager but not a programmer who wrote that code.

The way I see it Mat -- there are way more programmers than there are packagers 
on the GEOS / PostGIS teams, so YES I got to look out for the minority which 
has a major impact on the majority, because clearly no one else seems to.

> This brought incompatible toys in to the common sandbox.
What incompatible toys -- you still have your sandbox -- it's just a little 
more sandboxed.

> You do not want to recognize it.
I recognize it but I care much less about it than other things.  You're the one 
that turned in your keys to the GEOS project and said you didn't want to be 
part of it anymore.  I was extremely disappointed when you said that. So why 
this sudden new found interest?

> I'm not going to keep convincing you anymore.
Good cause we are in full agreement - we are just on opposite sides of the 


geos-devel mailing list <>

geos-devel mailing list

Reply via email to