[GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion
Vaclav Petras
wenzeslaus at gmail.com
Wed Feb 1 13:10:39 PST 2017
I did not include many details in the idea so here they are.
On Wed, Feb 1, 2017 at 11:59 AM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:
> I just the GSoC proposal for a "Higher level API for C and C++".
>
It it should not remove the existing API but build on to of it.
> I _think_ I understand where this comes from,
>
Good example is the random access to raster cells which runs in
all-in-memory and tiling-on-disk modes. Several modules need it, several
modules implement it in different ways. Segement library helps but solves
just part of the issue.
> but it does raise some very fundamental issues about how GRASS is written
> and should be written,
>
The implementation should stay the the intact, especially when talking
about GSoC. The point is to create a better API. Something link PyGRASS but
in C and C++. PyGRASS also uses existing C functions but wraps them in the
way they are easy to use (this would be case for C API) or more appropriate
to the language (C++).
> notably, but not only, the inclusion of a C++ API.
>
Add C++ API can be adding just few header files. Limiting the C++ API to
what "fits" into a header file has two advantages: same functionality needs
to be accessible in C API and it avoids (some/all?) issues of C++ linking.
>
> I just want to ensure that there is sufficient discussion on the list
> about such a project which could have far-reaching consequences. And if we
> ever decide to for such a project, then I think it has to be made
> absolutely clear that the student working on this needs to be extremely
> proficient in C/C++.
>
Agreed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170201/7ff95316/attachment.html>
More information about the grass-dev
mailing list