On Mon, 21 Jan 2002 22:39:07 +0000, David D Gray <ddgray@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@jps.net>
...