[GRASS5] Want GNU libavl ?

[Eric G. Miller]

On Mon, 21 Jan 2002 22:39:07 +0000, David D Gray <ddgray at armadce.demon.co.uk> wrote:

[snip]
> > Yes, I fully agree in principle. The problem is that I'm not aware of any
> > C equivalent of the STL, I mean, a set of container classes with consistent
> > interfaces. The containers mentioned above are coming from two different
> > libraries (libavl, www.purists.org), and if we need some other data 
> > structures some other sources
> 
> 
> Well, this is because C is not object-oriented, but I just meant that 
> containers would come from different sources and have arbitrarily 
> different entry points for the user (ie of the API), so it would help to 
> create some kind of wrapper library with conventions convenient to us, 
> so that a module author would not have the onerous task of setting up 
> datum structures, allocating keys and data and so on. It would just be a 
> matter of choosing the correct container and then it is one call to 
> initialise it and then start using it. Of course there would still be 
> some differences reflecting the different uses and capabilities of the 
> various containers.

Frankly, I think the object-oriented'ness is less the issue, than the fact
that most GRASS API's are very low level (or non-existent).  What is needed
is grouping common tasks/functionality into library routines so that there's
one consistent place to go to do X, rather than each module author having to
duplicate a lot of code in other modules.
 
> > could be used, coming from more different plances (which may lead to more
> > confusion, at least in principle...)
> > Is there anyone who is aware of a usable (GPL'd, LGPL'd) container library 
> > for the C programming language?
> 
> 
> I know that we have this long-standing policy of preferring ANSI C as 
> the central language for GRASS. But the truth is that few people _if 
> any_ today in engineering, research, academia use C as the development 
> language. It is almost universally C++ that is used. I think that we 
> have to accept that now and move on. We don't need to necessarily code 
> the core of GRASS in C++, but we should be able to wrap in external data 
> structures if these are only available (or the best implementations are 
> available ) in C++. Also reflect : Mitab, Dime ... the list goes on.

I think it's mostly a matter of pragmatism.  ANSI/ISO C89 works well pretty
much everywhere.  Also, GRASS has a lot of code.  Do you want to rewrite
it all?  One problem with C++, it's a one-way street.  Sure, you can write
C that is C++ friendly, but the reverse is difficult.  That a lot of other
folks are primarily using C++ for relatively new projects doesn't have
a lot of bearing, when you consider maintaining/enhancing an existing
code base written in C.

> > The only container library I'm aware of are for the C++ programming language,
> > the STL provided with libstdc++, the container library of the 
> > WxWindows framework (based on macros rather than on templates) and
> > STLPort (www.stlport.org, not sure about the license, anyway it's still
> > an STL implementation...).
> 
> 
> One of the things that's really lame about C++ is the poor general 
> support for some of it's features - core features in my view - like 
> exceptions and STL across the range of platforms. So much so that even 
> it's advocates generally recommend coding without relying on these 
> features. But it gets a bit of a headache when you create whole 
> development systems as a dependency for anyone who wants to build GRASS 
> if we choose to use implementations from other languages (like Ada/Gnat).

Well, if I had a choice between C++ and Ada95, I'd probably choose the
latter.  C++ keeps all the dangerous stuff of C and adds new ways to
shoot yourself in the foot.  I don't see requiring GNAT as fundamentally
different than requiring bison.  BTW, Ada should be supported in GCC 3.1,
as ACT donated their public GNAT to the GCC team.  I hope the GCC folks
give it due attention.

> > If I undestand correctly, the system of wrapper functions should be created
> > from the ground up, or we may accept the convention of a chosen library and
> > then adapt the other containers we need to these conventions...
> 
> 
> 
> Ground up in this case. But that might coincide largely with one of the 
> libraries, we just choose the most appropriate design.

Well, you'all are discussing something larger than what I was thinking of.
I think it's a good idea to some higher level data structures.  If you guys
want to work on such a thing, great.  It'd be nice to have standard things
like linked lists, queue's, stacks and trees along with the other basic
functions in libgis (and can we please change G_malloc and G_realloc not
to cast to a char * !!  What a pain that is.).  

-- 
Eric G. Miller <egm2 at jps.net>