[GRASS5] Want GNU libavl ?

[David D Gray]

Andrea Aime wrote:

> Alle 19:12, lunedì 21 gennaio 2002, David D Gray ha scritto:
> 
> [...]
> 
> 
>>Actually there is a simple binary tree from way back. Maybe a btree has
>>been added recently, I don't know, but we do need better container
>>support. I first came across this when I started on the import filters a
>>couple years back. In fact I first linked the v.in.shape binary against
>>Berkeley DB2 btree, which gave a good result, but introducing it at that
>>time was potentially a large job, and there were questions of platform
>>support and its a big package to bundle if it's to become a dependency.
>>
>>So I agree that a number of different containers could be included, and
>>it would also be good to have some kind of uniformity in the interface
>>to these, like a system of wrapper functions.
>>
> 
> 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.


> 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.


> 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).


> 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.

Regards

David