Xdg-list digest, Vol 1 #432 - 11 msgs

[Dave Cridland [Home]]

On Wed, 2003-07-23 at 11:19, David Faure wrote:
> On Wednesday 23 July 2003 06:43, Linas Vepstas wrote:
> > Do you actually have a proposal for something better?
> 
> Yes - what about splitting glib? IMHO it's fine to have a lib that provides
> linked lists and other containers, for C programs and libraries (if it is indeed
> proven that low-level libraries like Xr, freetype or Xft will want to use it).

Yes, this seems absolutely sane, and I entirely agree.

Many people present have argued that glib is lots of different things,
so is there any fundamental reason why it can't be split up?

Personally, I don't use glib directly at all - I prefer coding in C++,
precisely for the reasons given below. I feel relatively confident that
any container exported by glib could, however, be relatively easily
wrapped into something that looked and felt like an STL container (my
personal choice), or indeed anyone else's containers, and unless the
glib developers have done something badly wrong, efficiency and speed
should not be much different.

However, I'd distinctly prefer to see only PODs used in interfaces. I'm
not sure I'd really enjoy wrapping some glib-specific structure - or,
*shudder* "object" - into C++. int, unsigned int, char * - these are all
pretty portable between languages. Some form of canonical container set
seems fair, but I doubt anyone will really want to go further.

C++ (and indeed almost any language) may be able to use or wrap
essentially any C interface, but that doesn't mean you end up with
elegant code afterwards, and besides which, most C++ programmers chose
the language to get away from the muck of trying to do OO in C.

Of course, the specifications should be adequate enough that writing a
completely new implementation should be possible in any language, and
alternative implementations are always a good thing for this reason.

It does seem that we need a working group on reference implementation
API/ABI requirements.

Dave.