I did not include many details in the idea so here they are. On Wed, Feb 1, 2017 at 11:59 AM, Moritz Lennert < mlenn...@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.
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev