<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Yes, I agree that we should stay on the conservative side with regards to the API. How about we set up tests on travis and appveyor that checks that the API can be used in a strictly C89 application? Perhaps also a similar thing for the C++ API.
<div class=""><br class="">
</div>
<div class="">/Kristian<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 16 Jan 2019, at 18:05, Thomas Knudsen <<a href="mailto:knudsen.thomas@gmail.com" class="">knudsen.thomas@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">Thanks, Even, for elaborating on all the stuff I thought and meant, but didn't mention. It was exactly my main concern, that the interface should probably be kept C89(C90)-compatible for quite a while. The library-internal code, since compiled
as C++, can wiggle a lot more. All in all going C++11 is a huge improvement, as long as we can keep the C ABI/API reasonably stable/accessible from C and from projects expecting a C ABI.</div>
<div class=""><br class="">
</div>
<div class="">RFC3 is perfectly fine as is, but proj.h and the ABI and API it exposes needs special care. With that in mind, it is as Kristian indicates: A lot of C99 considerations are more or less irrelevant now that we compile everything as C++11.</div>
<div class=""><br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">Den ons. 16. jan. 2019 kl. 17.08 skrev Even Rouault <<a href="mailto:even.rouault@spatialys.com" class="">even.rouault@spatialys.com</a>>:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On mercredi 16 janvier 2019 15:53:34 CET Kristian Evers wrote:<br class="">
> Most of the code is now compiled as C++ so probably not a big issue in<br class="">
> practical terms.<br class="">
<br class="">
Yes and no. My point was that, in the current state of PROJ master, people can <br class="">
for example use a separately compiled PROJ with whatever "modern" compiler we <br class="">
require (or use a PROJ binary from their prefered packaging), but still <br class="">
wanting to use the PROJ C API with their own build constraints, like enforcing <br class="">
-std=c89 in their code base, and thus including proj.h with non-C89 features <br class="">
would break that.<br class="">
<br class="">
> Just to be clear, I have no intention of updating the RFC as it is now. I<br class="">
> don’t think the concerns raised here are incompatible with the content of<br class="">
> RFC3.<br class="">
<br class="">
RFC3 is fine for me as a general strategy. This is just a example of practical <br class="">
concrete decisions.<br class="">
I've sticked to using int in the new C API I've added in cases where bool <br class="">
might have been used.<br class="">
<br class="">
Even<br class="">
<br class="">
-- <br class="">
Spatialys - Geospatial professional services<br class="">
<a href="http://www.spatialys.com/" rel="noreferrer" target="_blank" class="">http://www.spatialys.com</a><br class="">
</blockquote>
</div>
_______________________________________________<br class="">
PROJ mailing list<br class="">
<a href="mailto:PROJ@lists.osgeo.org" class="">PROJ@lists.osgeo.org</a><br class="">
https://lists.osgeo.org/mailman/listinfo/proj<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>