Hi guys,
these are all good suggestions. And partly UNO has been designed in the
way you suggest. The UNO core/runtime is implemented in the cppu library
(which's name is, I have to admit, unfortunately misleading) and offers
a 'C' style interface only. This page
http://udk.openoffice.org/common/man/binspec.html
may suit as a starting point for reading.
The library cppuhelper is mainly providing helpers to implement, use and
bootstrap UNO. Unfortunately the bootstrap stuff is not available in the
cppu library yet, but could probably (easily) being added.
As suggested, names of libraries providing C++ interfaces already
differ, depending on the used compiler. E.g. cppuhelper is called
libuno_cppuhelpergcc3.so.3
where "gcc3" reflects the C++ ABI version. Unfortunately it is not
necessarily true, that libraries compiled with different (in terms of
ABI) C++ compilers can be used in the same process, because of symbol
conflicts. At least this is, what happened some times in the last years.
http://udk.openoffice.org/common/man/libraryversioning.html
should be provide some insights.
Language binding implementations don't need to use C++, but partly do
for convenience reasons. There is also a difference between cppu
supported language bindings (e.g. libgcc3_uno.so) and protocol based
bindings (like URP, http://udk.openoffice.org/common/man/spec/urp.html).
cppu based language bindings are mainly for in-process usage, improving
performance dramatically, where as protocol based bindings can be used
inter-process, inter-machine, inter-platform or inter-language and are
therefor in principal more general.
Hope that helps
Kay
Marten Feldtmann wrote:
I wrote this in the heise forum because I'm
considering an interface for Smalltalk, but
having only a C++ interface is simply making
the whole stuff much more complicated -
comparing against the possible API stuff of
MS Office (and I think its fair to compare OO
against MSOffice - even if OO is platform
independent - most of the users of OO are
also MS Windows users ...)
Designing a C interface may be more difficult
for the developers, but it will be much easier
for the users of such an interface.
Go away from language bindings at the first
level API and make a totally language independent
API with a defined call structure for C.
My comparisions in that posting were done with
ObjectOriented databases because I noticed the
same problems there - especially since Java
has grown in popularity.
Marten
I just noticed somebody else making a similar argument:
http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=8172098&forum_id=80089
That writer mentions that providing the C interface
first is the way to go; other languages' interfaces
are much easier to base on a C interface than on
a C++ interface. This is certainly something I've
heard in other contexts, too.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
