[Proj] Use of C++

[Kristian Evers]

I agree with Kurt and Even here. Regarding alienating contributors, this is not something
I am particularly worried about. At the moment we have less than 10 ten regular
contributors (interestingly enough, most of those who are against the use C++ in PROJ
don't really contribute themselves...). I often hear people say they are holding back on
contributing to the project because they find C89 ancient and absolutely intolerable to
work with. Your mileage may vary but I would argue that using a fairly modern language
(C++11) attracts more interest than using C89 which lacks many features the modern
Programmer expects in the toolkit today.

C++ is not perfect but it does offer some nice functionality that can greatly simplify the
existing code base in PROJ (e.g. string manipulation). And then there's all of the new
functionality which Even has already talked about length so I won't repeat those points.

Anyway, the wheels are in motion and Even has already come a long way with his work.
Instead of discussing the choice of tools I will instead encourage you all to review Evens
code and help him build it in the best way possible. This is a tremendous effort that when
finished will be a game changer in the world of GIS.

/Kristian

> -----Oprindelig meddelelse-----
> Fra: proj-bounces at lists.maptools.org [mailto:proj-
> bounces at lists.maptools.org] På vegne af Even Rouault
> Sendt: 27. maj 2018 21:01
> Til: proj at lists.maptools.org
> Emne: Re: [Proj] Use of C++
> 
> Joaquim,
> 
> >
> > 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.
> 
> We are speaking here about new code for new functionality. Existing code
> for
> now would remain in C.
> Your argument could be reversed: I'm a contributor to other C-written
> OSGeo
> projects where I would certainly contribute more to one project in particular,
> if dealing with its aging C code base wouldn't discourage me all the time
> (complicated memory management, painful string usage, etc...)
> 
> > Speaking
> > only from myself, but knowing I'm not alone, C++ is an awfully complicated
> > language
> 
> Agreed that mastering the whole C++ standard(s) can be awfully
> complicated.
> Subset of it can be much more manageable.
> 
> > that it was really
> > important but there were times I tried to contribute to GDAL but hit the
> > C++ wall.
> 
> Huh really? GDAL use of C++ is just C with classes, nothing too fancy
> generally ;-)
> 
> >
> > I also find the embedded systems argument a valid one but have poor
> > knowledge on the subject.
> 
> I'd bet people working in embedded systems heavily constrained like
> microcontrollers don't even use existing proj unmodified. They probably cut
> it
> down to the few projections they must use, have to replace/remove all the
> access to resource files, etc. Anyway the Linux kernel is written in C, but
> there are a number of low-cost platforms that cannot run recent version of it
> because it is too big and there are tensions in its community to know if it
> must try to accomodate for those uses
> 
> I believe that most contributors and users of proj are in the desktop/server
> segment. We can't address all potential use cases.
> 
> > What I have read here and there is that C++ codes
> > makes bigger and more resource demanding needs that those made with
> C.
> 
> That depends. This is not a general truth. It can also produce more optimized
> code.
> 
> >
> > That said, and as I mentioned in beginning, those that will implement the
> > new features have ofc the main word.
> 
> Honestly I can't imagine coding in C all those new functionalities. Basically
> the standards we want to implement is object oriented. I would spend too
> much
> time reimplementing object-like concepts with lot of verbose and error-
> prone C
> constructs (in a previous life, I've developed a complex project using GLib
> GObject C model [1]. It worked, but at what price...)
> 
> Even
> 
> [1] https://developer.gnome.org/gobject/stable/
> 
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj