Hi Dan,
Dan Kegel wrote:
Christian Junker <[EMAIL PROTECTED]> wrote:
[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 core is already 'C' based. Please see my other posting.
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.
What is disturbing here is, that it even (as you said) breaks in minors,
AFAIK even without notice, and sometimes it seems even without
intention. What is also disturbing, is the handling of libgcc_s.so,
which you on the one hand need to ship with program, but which partly
breaks binary compatibility on the other hand. Anyway, things are
improving and I am pretty sure they will be sorted out in the (near?)
future.
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++.
Actually, a C-library differs to C++-library only in terms of ABI and
does not need to differ in terms of implementation language. In other
words, it should be perfectly valid, to implement a library providing a
C interface in C++. The implementation language should really be an
implementation detail.
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.
We are are on it. Please see my other posting.
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.
My opinion here is, that sometimes it is more important to provide a
stable platform than to slow down adoption, e.g. by changing
interfaces/ABIs/APIs etc. No flame intended :-).
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.
Yep, were are quite aware of that. At least we have a clue of LSB 2.x :-).
- Dan
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
