<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC149" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line">More or less:<br></td></tr><tr></tr></tbody></table><span class="gmail-ui_qtext_rendered_qtext"><p class="gmail-ui_qtext_para">C++14 adds to C++11:</p></span><font size="2">Relaxed constexpr constraints</font></div><div class="gmail_default"><font size="2">Generic lambdas (e.g., <code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun">[](</span><span class="gmail-kwd">auto</span><span class="gmail-pln"> p</span><span class="gmail-pun">)</span><span class="gmail-pln"> </span><span class="gmail-pun">{</span><span class="gmail-pln"> </span><span class="gmail-kwd">return</span><span class="gmail-pln"> p</span><span class="gmail-pun">*</span><span class="gmail-lit">2</span><span class="gmail-pun">;</span><span class="gmail-pln"> </span><span class="gmail-pun">}</span></code>)</font></div><div class="gmail_default"><font size="2">Init-capture (e.g., <code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun">[</span><span class="gmail-pln">i </span><span class="gmail-pun">=</span><span class="gmail-pln"> </span><span class="gmail-lit">2</span><span class="gmail-pun">](</span><span class="gmail-kwd">auto</span><span class="gmail-pln"> p</span><span class="gmail-pun">)</span><span class="gmail-pln"> </span><span class="gmail-pun">{</span><span class="gmail-pln"> </span><span class="gmail-kwd">return</span><span class="gmail-pln"> p</span><span class="gmail-pun">+</span><span class="gmail-pln">i</span><span class="gmail-pun">++;</span><span class="gmail-pln"> </span><span class="gmail-pun">}</span></code>)</font></div><div class="gmail_default"><font size="2">Variable templates<code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-kwd"><br></span></code></font></div><div class="gmail_default"><font size="2"><span style="font-family:monospace,monospace"><code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-kwd">decltype</span><span class="gmail-pun">(</span><span class="gmail-kwd">auto</span><span class="gmail-pun">)</span></code></span><br></font></div><div class="gmail_default"><font size="2">Deduced return types<code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun"></span></code><br></font></div><div class="gmail_default"><font size="2">Binary literals (e.g., <code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-lit">0b11101100</span></code>)<code class="gmail-prettyprint gmail-inline gmail-prettyprinted"></code><br></font></div><div class="gmail_default"><font size="2">Digit separators (e.g., <code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-lit">0b1110</span><span class="gmail-str">'1100</span></code>)<code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun"><br></span></code></font></div><div class="gmail_default"><font size="2"><code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun"><span class="gmail-ui_qtext_rendered_qtext">Extend
 “aggregate class type” to include a class that would be a C++11 
aggregate type if default member initializers were omitted</span></span></code></font></div><div class="gmail_default"><font size="2"><code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun">[[</span><span class="gmail-pln">deprecated</span><span class="gmail-pun">]]</span></code> and <code class="gmail-prettyprint gmail-inline gmail-prettyprinted"><span class="gmail-pun">[[</span><span class="gmail-pln">deprecated</span><span class="gmail-pun">(</span><span class="gmail-str">"msg"</span><span class="gmail-pun">)]]</span></code></font></div><div class="gmail_default"><br></div><div class="gmail_default">So the question is:</div><div class="gmail_default">How much GEOS need those new features?</div><div class="gmail_default">Its not using a lot of features of C++11 anyway</div><div class="gmail_default"><br></div><div class="gmail_default">with c++ you can still use unique_ptr</div><div class="gmail_default">I have a lot of (stalled) work in this branch<br></div><div class="gmail_default"><a href="https://github.com/cvvergara/geos/tree/gPolygonizer">https://github.com/cvvergara/geos/tree/gPolygonizer</a></div><div class="gmail_default">where the intention is to use more the unique_ptr and/or shared pointer</div><div class="gmail_default">For example:<br></div><div class="gmail_default"><a href="https://github.com/cvvergara/geos/commit/f6c12cf17a40ddbe3b7e88b63728aac104ab8efa">https://github.com/cvvergara/geos/commit/f6c12cf17a40ddbe3b7e88b63728aac104ab8efa</a></div><div class="gmail_default"><br></div><div class="gmail_default">C++11 I think is good enough<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span class="gmail-ui_qtext_rendered_qtext"><p class="gmail-ui_qtext_para"></p></span></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 6:31 PM Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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...<div><br></div><div><a href="https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11" target="_blank">https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11</a><br></div><div><a href="https://trac.osgeo.org/geos/wiki/RFC5" target="_blank">https://trac.osgeo.org/geos/wiki/RFC5</a><br></div><div><br></div><div>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.</div><div><br></div><div><a href="https://github.com/abseil/abseil-cpp/blob/master/absl/memory/memory.h" target="_blank">https://github.com/abseil/abseil-cpp/blob/master/absl/memory/memory.h</a><br></div><div><br></div><div>For deprecated, can just start with something simple like ABSL_DEPRECATED.  And drop it when you can.</div><div><br></div><div><a href="https://github.com/abseil/abseil-cpp/blob/master/absl/base/macros.h#L134" target="_blank">https://github.com/abseil/abseil-cpp/blob/master/absl/base/macros.h#L134</a><br></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 11:34 AM Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Regina Obe" <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>> writes:<br>
<br>
> I think a lot of packaging (for older systems I see) I see is still<br>
> done on gcc 4.7.  Though one can argue that these older systems will<br>
> not ship newer GEOS, so might not be so much of an issue aside from<br>
> users who build their own GEOS stuck on old platforms.<br>
<br>
A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris, and<br>
the rest of the vendor unix tradition) there is usually a notion of<br>
"base system" and "packages or other stuff".  So with have things like<br>
mv and the compiler in base, and then packages, the idea of wanting to<br>
build newer packages with a not bleeding edge but not ancient compiler<br>
(which describes gcc 4.8) is not really that strange.<br>
<br>
<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-99621496119928301gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>

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

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl

<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>