On 05/07/2013 11:49 PM, glen herrmannsfeldt wrote:
> James Kuyper <
james...@verizon.net> wrote:
>> On 05/07/2013 06:51 PM, deech wrote:
>>> Hi all, I am not an experienced C developer and would like to know if
>>> there are good resources for, or better yet real-world examples of,
>>> wrapping a C++ library in C such that application written using it
>>> don't need to have the underlying C++ library.
>
>> There's a fundamental conflict built into your concept. You'll have to
>> resolve that conflict before you can do anything useful. Do you want to
>> wrap the C++ library, or replace it? A wrapper, by definition, calls the
>> function that it is a wrapper for; you can't have a working wrapper if
>> you don't have a working copy of the wrapped function.
>
> Well, the wrapped function doesn't have to call (directly or
> indirectly) C++ library routines. Most will, but some might not, ...
Huh? It doesn't matter whether the wrapped function calls other C++
library routines; the fact that the wrapped function is itself a C++
library routine is sufficient for there to be a problem. If the library
containing the wrapped function is not available, the wrapping function
can't work.
...
> ... and
> it might not be so hard to change the calls, for example to C library
> calls instead.
Well, first he'd have to write C library functions corresponding to the
C++ library functions he wanted to make wrappers for. He didn't indicate
which functions he was thinking of wrapping; he didn't even mention
which library they were from, so we have no way of knowing how difficult
of a task that might be. However, if writing equivalent C code were a
trivial task, I doubt he'd be thinking about using wrappers.
Later messages on another branch of this thread have clarified that his
issue is about the distinction between what, in a unix context, would be
described as static vs. dynamic linking. If the wrapped function is part
of a shared-object C++ library that is dynamically linked, it's a
problem if that library is not installed on on the machine where the
program will be executed. What he describes as a "fat executable"
corresponds to linking in the library statically. The same issue comes
up in other operating systems, but the description above might need
appropriate modifications.
--
James Kuyper