I just found a site concerning geometric algorithms (GPL):

--
easy access to useful, reliable geometric algorithms

The CGAL library contains:

* the Kernel with geometric primitives such as points, vectors, lines, predicates for testing things such as relative positions of points, and operations such as intersections and distance calculation.
* the Basic Library which is a collection of standard data structures and geometric algorithms, such as convex hull in 2D/3D, (Delaunay) triangulation in 2D/3D, planar map, polyhedron, smallest enclosing circle, and multidimensional query structures.
* the Support Library which offers interfaces to other packages, e.g., for visualisation, and I/O, and other support facilities.
--

you may already know this site but in case you don't it might be worth a look.

I know that GRASS is ANSI-C and these libraries are C++ but perhaps some problem can be solved using these libraries.

It would be fantastic to have a version of this library
in GRASS 6.1.
I could think of a dozen generally useful GRASS modules
based on this: 3D convex hull, converting 3D polygons to voxels,
point in 3D polygon queries ...
I don't know much C++, but surely there
must be a way to use the methods in this library with
standard C function calls? Some sort of simple wrapper perhaps?

Benjamin

Martin Wegmann wrote:

Dear GRASS developers,

I just found a site concerning geometric algorithms (GPL):

--
easy access to useful, reliable geometric algorithms

The CGAL library contains:

* the Kernel with geometric primitives such as points, vectors, lines, predicates for testing things such as relative positions of points, and operations such as intersections and distance calculation.
* the Basic Library which is a collection of standard data structures and geometric algorithms, such as convex hull in 2D/3D, (Delaunay) triangulation in 2D/3D, planar map, polyhedron, smallest enclosing circle, and multidimensional query structures.
* the Support Library which offers interfaces to other packages, e.g., for visualisation, and I/O, and other support facilities.
--

you may already know this site but in case you don't it might be worth a look.

I know that GRASS is ANSI-C and these libraries are C++ but perhaps some problem can be solved using these libraries.

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

On Fri, May 05, 2006 at 03:01:59PM +0200, Benjamin Ducke wrote:

It would be fantastic to have a version of this library
in GRASS 6.1.
I could think of a dozen generally useful GRASS modules
based on this: 3D convex hull, converting 3D polygons to voxels,
point in 3D polygon queries ...
I don't know much C++, but surely there
must be a way to use the methods in this library with
standard C function calls? Some sort of simple wrapper perhaps?

Calling C funcs from C++ is straight-forward.
The reverse is not possible, the whole result would be a C++ prog.

> It would be fantastic to have a version of this library
> in GRASS 6.1.
> I could think of a dozen generally useful GRASS modules
> based on this: 3D convex hull, converting 3D polygons to voxels,
> point in 3D polygon queries ...
> I don't know much C++, but surely there
> must be a way to use the methods in this library with
> standard C function calls? Some sort of simple wrapper perhaps?

Calling C funcs from C++ is straight-forward.
The reverse is not possible, the whole result would be a C++ prog.

It's not quite that bad. You can write C-callable wrapper functions in
C++, e.g.:

Note that the GLU library is written in C++, but can be used from C
programs.

Oh, yes, but that's C++, isn't it? The resulting code will link C++
objects with all consequent headaches (e.g. obscure ABI changes from
time to time) and C++ run-time on the shoulder.
That's what I pointed with my first sentence, C code can be called
by C++, but not viceversa.

> > Calling C funcs from C++ is straight-forward.
> > The reverse is not possible, the whole result would be a C++ prog.
>
> It's not quite that bad. You can write C-callable wrapper functions in
> C++, e.g.:
>
> extern "C" {
>
> void wrapper(void *p)
> {
> ((Object *) p)->method();
> }
>
> }
>
> Note that the GLU library is written in C++, but can be used from C
> programs.
>

Oh, yes, but that's C++, isn't it?

Yes.

The resulting code will link C++
objects with all consequent headaches (e.g. obscure ABI changes from
time to time) and C++ run-time on the shoulder.
That's what I pointed with my first sentence, C code can be called
by C++, but not viceversa.

Er, the above is C++, but it can be called from C.

GRASS code should avoid using C++ where possible, but we already
depend upon some libraries which are written in C++, most notably
GDAL, which is a mandatory dependency in 6.x.

If there's a particularly useful third-party library, we shouldn't
ignore it just because it is written in C++. However, anything which
uses it should first create a set of C wrappers (if the the library
doesn't already provide them) and use those, rather than using the C++
interface directly. If more than one module uses the library, the C
interface should either be made into a library or, where possible,
contributed back for inclusion into the original library.

GRASS code should avoid using C++ where possible, but we already
depend upon some libraries which are written in C++, most notably
GDAL, which is a mandatory dependency in 6.x.

Does this mean, the next release of GRASS is intended to ship with a
version of GDAL included?
This would be a blessing for people tired of the circular GRASS and
GDAL recompile game.

If there's a particularly useful third-party library, we shouldn't
ignore it just because it is written in C++. However, anything which
uses it should first create a set of C wrappers (if the the library
doesn't already provide them) and use those, rather than using the C++
interface directly. If more than one module uses the library, the C
interface should either be made into a library or, where possible,
contributed back for inclusion into the original library.

I searched the web quickly and there does not seem to be any C wrappers
for CGAL yet. It's a fairly complex library, but maybe the most
important bits wouldn't be so hard to wrap ...

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Does this mean, the next release of GRASS is intended to ship with a
version of GDAL included?

No. It is too much work to keep all dependencies in sync and up to date.
This is a job for packagers to take care of, the source code must stay
generic.

This would be a blessing for people tired of the circular GRASS and
GDAL recompile game.