The main problem with C++ is not exceptions or RTTI, but the internal "name mangling" that turns object methods into discernible internal entry points (function names).
Two workarounds for this are
1) provide source code so that users of this code can build the library
with their own C++ compiler. This makes it difficult to use from
other, non-C++ languages/environments and complicates use of the library.
2) provide C interfaces (actually C function calls, with non-managled names
and a well-known parameter passing mechanism). This is more difficult
for the developers but makes the library easier to use by all sorts of
environments.
C interfaces remain the "lingua franca" of binary object modules
(unless you believe the C# people, but I don't). The only good idea behind
C# is the common object module format -- something which should have been
dealt with a decade ago -- but that too has many constraints. I think of
it as more of a totalitarian regime which says, "if only everyone did it our
way, the world would be so much better." Well, probably not.
Scripting languages, like Python, Ruby, Lua, Perl, etc. are emerging as "system
glue" which are alternatives to using C. I think this is a good trend. If I
had to pick a direction in which to go, one or several of these languages/environments
would be the way I'd do it (and still provide C APIs).
jeff
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
