Christian Junker <[EMAIL PROTECTED]> wrote:
2005/6/9, Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]>:
... we are going to factor out ... Universal Network Objects (UNO)
into its own Uno Runtime Environment (URE)
The URE allows the usage of UNO independently of the
OpenOffice.org<http://OpenOffice.org>
productivity suite. UNO is OpenOffice.orgs underlying component model,
allowing language agnostic and remote transparent development of
add-ins, components and applications.
As UNO has already been designed with independence in mind, the URE is
mainly about bundling the appropriate libraries, executables etc. into
their own package. Please have a look at the URE proposal at
http://udk.openoffice.org/common/man/draft/standalone_uno_1_0.html
>
> Wonderful! I remember talks on this mailinglist but back then it was not
> clear when this would be achieved. In my eyes UNO can even compete with COM.
>
> By the way, I also heard about transforming the UNO code base from C++ to C
> to gain performance, is there such a plan in the future?
[Apologies if I'm treading old ground, or anyone's toes, or spouding nonsense.
I have hardly looked at the UDK before. I do have some experience
supporting multiple versions of g++, though.]
Is that practical? If it is, it might be a good idea.
The C++ ABI on Linux is a moving target;
it has changed with every minor release of gcc
(except 4.0, which uses the same ABI as 3.4). The C++ ABI
will be changing again with gcc-4.1.
That means that there is essentially no hope of having
a single binary library written in C++ ship and work with
all Linux distributions. (I'm exaggerating here, but only a little.)
There are extremely good reasons for the ABI changes (and I'm pushing for
one of the ABI changes in gcc-4.1, so I'm glad it's happening),
so I'm not criticizing the gcc developers, simply stating the facts.
The C ABI on Linux, on the other hand, remains relatively rock-solid.
Any low-level library that wants to have a hope of being
universally usable should strongly consider being based
solely on C and not on C++.
Now, the UDK has to have C++ bindings for
convenience of C++ developers. It might be worth considering
making these bindings available for multiple versions of
the Linux C++ ABI simultaneously on the same machine
(via different shared library major version numbers, perhaps).
This would be possible if (and perhaps only if) the guts
were in C, so the C++ binding really was just a shallow
adaptor.
Finally, on an optimistic note, I do think the rate of change in the C++ ABI
is slowing down, and there's a chance that the gcc-4.1
C++ ABI will last a couple years, and might even
(as part of LSB 4.0) be around for a decade.
I'd also like to point to the LSB (Linux Standard Base) as
a source of hope; LSB 3.0 will provide an island of stability
for C++ apps which might let you ignore some of the above issues
at the cost of having to help cheerlead LSB adoption.
- Dan
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
