[GRASS5] Want GNU libavl ?

[Andrea Aime]

[...]

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

I agree...

> > 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 agree here, too... I definitely prefer OO programming, but that's
mine (and yours) preference... I would like to know what the other
developers think about this issue... in fact I think that having a C++
wrapper over the current libraries could attract some more
developers...

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

Yes, that's why the KDE project refuses to use exceptions and sticks
to QT containers, less powerful than STL ones but more portable

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

Yes. BTW, by having C++ wrappers we could also create some 
bindings to other languages (Python, Java, and so on, the QT/KDE bindings are
generated by a semi-automated procedure as far as I know)

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