[GRASS5] Want GNU libavl ?

[Robert Lagacé]

I think that it is a decent proposition.  

I recommand that we use the gidelines used by the wxWindows project: 

http://wxwindows.org/standard.htm

wxWindows is a very large project compiled on many platforms with 
differents C++ compilers.  

I would like to make another proposal maybe for GRASS 6 : put in 
libraries (which is already started) all computationnal stuff and 
use Python as the glue logic (interfaces, user interaction, applications, 
etc.).  We will retain the avantages of shell scripts without all 
the problems associated with shell scripts.  Plus, we will gain an 
free interpreter equivalent to MapBasic and the one used in ArcInfo. 
With this, we open the possibility for users to write their own 
applications.  I invite those interested to look to wxPython, an 
interface wxWindows to python and run the demo.

Frank Warmerdam wrote:
> 
> David D Gray wrote:
> > We could talk about this for ever, but it can only be put to the test
> > when a developer comes up with a specific proposal with genuine merit
> > for  including or writing a component in C++ (or other language).
> 
> Folks,
> 
> I hardly want to be a proponent of "C++ ification" of GRASS; however, I
> would like to see the GRASS build system attempt to identify a C++ compiler
> that can be used (normally just g++ of course) and to support building C++
> modules.
> 
> For the time being I think we should avoid using C++ in libraries but I
> think we should open up the option of some programs being in C++.
> 
> For r.in.gdal I have used a C "wrapper" api over GDAL which is internal
> a bunch of C++ classes.  However, OGR, my vector library, has no such
> C wrapper and I am not terribly inclined to write one.  However, I would
> like to write a vector import and export capability based on OGR for
> GRASS and that program would have to be in C++.
> 
> Therefore, I propose that for GRASS 5.1 we open up the option of some
> GRASS programs (hopefully non-essential ones) be written in C++.  Hopefully
> from this we will get a better sense of what portability problems we will
> encounter with C++.  Then in GRASS 5.2 we can consider allowing some C++
> code in the core libraries.
> 
> Even then, I would discourage attempts to rewrite large chunks of code to
> be C++ friendly just for the sake of it.  In past projects I have found this
> can lead to corruption of what had been a clean C library.
> 
> Even if we allow C++, we might want to place some restrictions on it.  For
> instance, I avoid all use of RTTI, exceptions and templates in GDAL to avoid
> portability problems.
> 
> Best regards,
> 
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

-- 
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace at grr.ulaval.ca