[GRASS5] Re: c++ question

GRASS GRASS developer
,
1

Helena, Laura
(cc grass5)

[Laura, the MailMan was catching your mail, only subscribers
can post... sorry. This avoids spamming.]

On Wed, Aug 07, 2002 at 07:36:47PM -0400, Helena wrote:

Markus,

you might have noticed Laura's question about the c++ code - originally
she wanted to implement her old c-code, but that one did not have lot
of capabilities that we needed so she is trying to do it with the newer
c++ version of terraflow. I told her to look at gdal code which is c++,
but I am not sure whether that would work for her. It would be good to
do this with the future structure of grass code in mind - do you have any
advice for this, or who would be a good person to contact?

from the previous discussions about C++ there was some consensus not
to introduce C++ intro GRASS directly. But: GDAL contains a C wrapper
around the C++ functions which are needed for the interface (called
"GDAL bridge").
Laura, maybe you can wrap the interfacing functions of your code to C?

The same we expect for OGR (the vector counterpart for GDAL raster),
a C wrapper ("OGR bride" or so). Frank Warmerdam has developed the
GDAL bridge. It's part of GDAL (subdirectory bridge):
http://remotesensing.org/gdal/

I am rather sure that core GRASS remains C, but such wrappers may
establish the connection to C++.

There is also the "libgrass" containing I/O routines of GRASS (the related
C functions extracted for that package). I am using that for
GRASS/MapServer.

Maybe the other developers have a different opinion?!

Markus

2

On Thursday 08 August 2002 08:51 am, you wrote:

...

Maybe the other developers have a different opinion?!

I'm starting to think on how to setup my net-analysis daemon idea.
There is the issue of the xml parser technology. I would prefer to use
xercesc++. This is more about calling c from a c++ module. Will GRASS
makefile system support c++ in g51?
I do not yet know the Frank's GDAL bridge system but I think it would be too
hard to do the xerces wrapper.
Ciao.

3

r.in.gdal is a bit different from what I am doing. GDAL provides functions
which are heavily used by developers of other modules. I can see why you
want a C wrapper around it. I'm trying to write an 'independent' module
similar with r.watershed, or r.flow. I don't expect to be used internally
in other parts of GRASS. In any case, the function that computes flow is
actually in C, so I could think of that as the wrapper.

The part that's in C++ is the I/O-efficient library, containing
implementation for I/O-efficient streams, I/O-efficient sorting,
I/O-efficient priority queue, lists and so on. If at some point we'll
want to make that a separate library usable by other modules, that will
have to be wrapped in C. But for now it is just inside my module.

thanks, I'm all set for now
-Laura

On Thu, 8 Aug 2002, Markus Neteler wrote:

Helena, Laura
(cc grass5)

[Laura, the MailMan was catching your mail, only subscribers
can post... sorry. This avoids spamming.]

On Wed, Aug 07, 2002 at 07:36:47PM -0400, Helena wrote:
> Markus,
>
> you might have noticed Laura's question about the c++ code - originally
> she wanted to implement her old c-code, but that one did not have lot
> of capabilities that we needed so she is trying to do it with the newer
> c++ version of terraflow. I told her to look at gdal code which is c++,
> but I am not sure whether that would work for her. It would be good to
> do this with the future structure of grass code in mind - do you have any
> advice for this, or who would be a good person to contact?

from the previous discussions about C++ there was some consensus not
to introduce C++ intro GRASS directly. But: GDAL contains a C wrapper
around the C++ functions which are needed for the interface (called
"GDAL bridge").
Laura, maybe you can wrap the interfacing functions of your code to C?

The same we expect for OGR (the vector counterpart for GDAL raster),
a C wrapper ("OGR bride" or so). Frank Warmerdam has developed the
GDAL bridge. It's part of GDAL (subdirectory bridge):
http://remotesensing.org/gdal/

I am rather sure that core GRASS remains C, but such wrappers may
establish the connection to C++.

There is also the "libgrass" containing I/O routines of GRASS (the related
C functions extracted for that package). I am using that for
GRASS/MapServer.

Maybe the other developers have a different opinion?!

Markus