Category Archives: General

Xerces-C++ header installation

My stubborn re-posting and repeated re-explaining in the Xerces-C++ mailing list has finally paid off with a response
from a maintainer and a vote that’s underway. The issue?
Putting the include files under prefix/include/xercesc
instead of prefix/include. Such a minor thing has taken a
ridiculous amount of effort. I believe that it’s partly due
to the fact that there’s not 1 or 2 maintainers, but a set
of many people of varying responsibility. If there was any
alternative C++ XML parser then I would have walked away
from this in frustration. It’s very unfortunate because the
actual source code of Xerces-C++ is wonderful.

I don’t look forward to the same thing over the issues of
proper versioning, binary/API compatibility between stable
releases, release planning, and binary packaging for
distributions. The lesson? Just do things the standard way
from the start. Use autoconf/automake.

C++ reference-counting smart pointers

;I finally took the time to figure out how to implement C++ reference-counting smart pointers: Of course you just
copy a
pointer to a counter in the copy constructors. And, by
adding an allocator type to the template specification, it
can even be used to wrap C types that have special
allocation and deallocation functions, without repetition of
code in the derived classes. This has been on my TODO list
for so long that I feel an overwhelming sense of well being
from having found such a simple solution.

DBTools.h++

Work has become a bit frustrating. I’ve had to discard Roguewave’s DBTools.h++ library because the only version
that compiles is the one that prevents use of the C++
Standard Library in the same application. They have a new
version that will work, but they’ve changed the license so
that they charge for deployment. It really seems
that Roguewave is dying and is just tryingt to shaft its
locked-in customers for as much money as possible while its
code stagnates.

So I’m having to wrap the Sybase C client library myself.
It’s so old that’s it’s written in K&R C – the old-style
C with the bizarre function declarations. And that’s just
the start of it’s weirdness. I wish that there was an open
source equivalent of DBTools.h++, but I’m not the guy to
start one.

In real-life, I’ve recruited a few more climbers in
Munich, but I’m having trouble getting them into a regular
routine. Unfortunately, it’s already August and there can
only be a few more summer weekends left.

Microsoft Binary Compatibility

I just read in miguel‘s activity log about how Microsoft have a great understanding of binary
compatibility. Actually they have an appalling record on
binary compatibility and/or proper library versioning. And
several of their critical updates have made Windows
installations unbootable because of this. And worse, they
won’t even admit such problems until they’ve got the next
version out weeks later.

Gtk– 2

The more I use QT at work , the more I loath it. It has spurred me to get Gtk– 2 moving along, but it’s hard going
without kenelson, who seems to be having
some connectivity problems.

Some thoughts about Mono

Some thoughts about Mono: It competes with Microsoft in the only areas in which they are vulnerable -technical competency, rate of development, cost, and
possibly technical support. In the real world, I suspect
that its major advantage for Ximian will be as a way to
secure extra funding by associating themselves with this
quarter’s big thing.

Admittedly, I haven’t bothered to investigate .NET, but
after
in-depth experience of development with Microsoft tools and
APIs in the past, I have very little confidence in the
technical merits of .NET. And having followed tech-news for
many years, it is clear to me that MS uses business
relationships to gradually make other companies critically
dependent on them, and then withdraws cooperation as soon as
it is clear that doing so would destroy the other company,
or at least destroy the project.

Guillaume and chakie asked me to clarify my whingeing about the QT API

Guillaume and chakie asked me to
clarify my whingeing about the QT API in my previous entry.
Here’s what I told
Guillaume. He said that most of these points weren’t
significant, not really to my satisfaction. I’d post his
comments, but it was a person-to-person email thread.

> > I suppose you’re mostly thinking of the containers here,
as the widgets API is quite orthogonal IMHO. :-)

Orthogonal is maybe not the best word. In particular I
dislike the:

  • Duplication of menu APIs.
  • The confusing way that the constructors are overriden
    so
    that argument position is more important than argument
    type.
  • The way that add-to-parent is implicit in the
    construction
    of the widget.
  • The way that add-to-parent means different things
    depending on the type of the child, again implicitly. e.g.
    Layouts are not children in the same way that widgets
    are.>> Can you show me an example of what you think is
    “inadequate functionality” ?

    • The QTable has a tiny, inadequate, API.
    • There is no Document/View
      framework.
    • I do not find the choice of QLayouts very useful,
      but maybe I need to go beyond QGridLayout.

    Of course my dislike of pre-processor and non-standard
    containers is well known. We had a clear and sensible
    discussion of these issues in <a
    href=”http://news.gnome.org/993658952/993677931/993691427/993718928/index_html”>this
    gnotices thread.