[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