[geos-devel] C++14

[Vicky Vergara]

More or less:

C++14 adds to C++11:
Relaxed constexpr constraints
Generic lambdas (e.g., [](auto p) { return p*2; })
Init-capture (e.g., [i = 2](auto p) { return p+i++; })
Variable templates
decltype(auto)
Deduced return types
Binary literals (e.g., 0b11101100)
Digit separators (e.g., 0b1110'1100)
Extend “aggregate class type” to include a class that would be a C++11
aggregate type if default member initializers were omitted
[[deprecated]] and [[deprecated("msg")]]

So the question is:
How much GEOS need those new features?
Its not using a lot of features of C++11 anyway

with c++ you can still use unique_ptr
I have a lot of (stalled) work in this branch
https://github.com/cvvergara/geos/tree/gPolygonizer
where the intention is to use more the unique_ptr and/or shared pointer
For example:
https://github.com/cvvergara/geos/commit/f6c12cf17a40ddbe3b7e88b63728aac104ab8efa

C++11 I think is good enough


On Thu, Dec 13, 2018 at 6:31 PM Kurt Schwehr <schwehr at gmail.com> wrote:

> Getting people to be willing to drop support for old compilers is really
> difficult.  Especially without people who can provide strong support for
> older branches of all the related code bases.  A bunch of discussion went
> into the topic for these 2 RFCs...
>
> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
> https://trac.osgeo.org/geos/wiki/RFC5
>
> C++14 isn't that huge of a jump and if there are features that people
> really want that are available in libs like abseil, it isn't unreasonable
> to port a copy into a private namespace of GEOS and use it until it can be
> refactored out when the minimum compiler make the standin irrelevant.  e.g.
> make_unique is here and could be converted to geos::private::make_unique or
> some such.
>
> https://github.com/abseil/abseil-cpp/blob/master/absl/memory/memory.h
>
> For deprecated, can just start with something simple
> like ABSL_DEPRECATED.  And drop it when you can.
>
> https://github.com/abseil/abseil-cpp/blob/master/absl/base/macros.h#L134
>
> On Thu, Dec 13, 2018 at 11:34 AM Greg Troxel <gdt at lexort.com> wrote:
>
>> "Regina Obe" <lr at pcorp.us> writes:
>>
>> > I think a lot of packaging (for older systems I see) I see is still
>> > done on gcc 4.7.  Though one can argue that these older systems will
>> > not ship newer GEOS, so might not be so much of an issue aside from
>> > users who build their own GEOS stuck on old platforms.
>>
>> A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris,
>> and
>> the rest of the vendor unix tradition) there is usually a notion of
>> "base system" and "packages or other stuff".  So with have things like
>> mv and the compiler in base, and then packages, the idea of wanting to
>> build newer packages with a not bleeding edge but not ancient compiler
>> (which describes gcc 4.8) is not really that strange.
>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
>
> --
> --
> http://schwehr.org
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel



-- 

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky at georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181216/15fcdfbb/attachment.html>