Wham Bang wrote:

> I don't want to start a language flamewar or anything, so I don't
> think I want to get very deeply into this...

Although a decision about this issue is ultimately going go determine
the development language, I do not consider this a discussion about
what language is better. I am not on a crusade against C++. I only
object to C++ libraries, because the amount of problems involved are
larger than with C libraries.

> So maybe you have an optional extern C wrapper layer around your
> C++ library? Certainly not unheard of.

Sure, we do so at work, and it is very inconvenient. Let me state
a few problems

o How do you wrap templates or overloaded functions and operators?
  The point here is that in order to be able to make C wrappers, you
  have to devoid your C++ interface of most C++ features (it may even
  be reduced to only having an implicit object reference (the 'this'
  pointer)).
o To use these libraries in Java (the same argument applies to most
  other languages that supports C linkage) you've got to have a C
  linkage library. This means that you end up with two libraries:
  a C++ library and a C library which contains the C++ library plus
  a C shell (with C++ wrappers you can usually put all wrapper code
  into the header file, resulting in only one library).
o If the library returns dynamically allocated memory that the
  application is responsible of freeing, you cannot use the 'new'
  operator to allocate this memory. The problem is that in C you
  cannot use the 'delete' operator, and it is illegal to deallocate
  such memory with 'free' (on some platform it will even corrupt the
  heap).
o If the library uses global objects (for example, it would make
  sense to have a global DNS resolver in libcurl) then the C wrappers
  have to call the global constructors/destructors, which is a hairy
  task, because it has to be done differently on various platforms and
  compilers (and has to make use of undocumented features in some
  compilers).

> > 2) [...] you have to use the same compiler to build
> > the library and to build the application [...]
>
> If it's a different language than C++, see #1. And if it's a C++
> application, since we're talking about an open-source project,
> I do not feel this to be a restriction. Am I missing something?

It is not uncommon to compile stand-alone libraries with vendor
compilers to achieve maximum performance, and the applications with
cross-platform compilers (such as gcc) to achieve maximum portability.
It is also not uncommon to have two separate projects on the same
machine, where one is built with a vendor compiler and the other with
gcc (for the same reasons stated above) -- such projects usually share
libraries. That would not be possible with a C++ library, due to name
mangling.

> Any library designer, regardless of language, imposes design
> restrictions on his users. It is the tradeoff the users have to
> make in order to avoid implementing the whole thing themselves.

I agree with that, but my point was, as attested by my examples,
that with C++ you have to be much more careful how you design and
implement your library.

> The only issue that is, IMHO, serious is that of allowing linkage
> for users of other languages. And I feel that a proper (and

I agree that this is the most serious problem. However, the other
problems are still present.

> pretty easily implemented) solution for *that* is to have an
> optional C wrapper around your C++ library. I think it's easier

The other way around.

> to properly and cleanly design the library in an OO way and
> provide some procedural interface to it, than it is to do it
> the other way around.

Building a C library does not exclude an OO design. If you look
at the proposals made last year, you will notice that they are
OO to some extend (the use of a handle roughly equates an object).
The internals of libcurl is mainly network code and similar
low-level code that may not benefit significantly by other OO
techniques.

The message I am trying to bring across here is that although C++
libraries looks nice on paper (and especially if you are developing
your applications in C++), there are just so many pitfalls that it
is not worth the trouble, and it introduces too many practical
restrictions on developers of non-C++ applications.

All of the above problems are technically solvable, but they are
non-existant with a C library and C++ wrappers, so why go through
the trouble? What gain can C++ bring us (with the possible exception
of STL) that can outweight the mentioned difficulties? Libcurl can
certainly benefit from OO elements, but that does not exclude C as
the development language.
Received on 2000-04-02