Re: C++ and shared objects
On 9 Feb, 18:26, Robert Fendt <rob...@fendt.net> wrote:
And thus spake James Kanze <james.ka...@gmail.com>
Mon, 8 Feb 2010 14:39:06 -0800 (PST):
The interface (both under Unix and under Windows) allows for
loading just about anything. (Windows is somewhat more
restrictive here, I think.) All you have to do is give the
name according to the local conventions, which means mangled
in the case of Windows or Unix. On the other hand, you also
have the problem that the function returns a void* (Unix) or
a void (*)() (Windows), which means you'll also need some
casting. And no doubt, headers, to define what you'll be
casting to. In practice, because of the mangling, the
easiest solution is to provide an ``extern "C"'' factory
function. (Typically, the mangling used by C is far simpler
than that used by C++.) But the client code still needs the
header files to know the target type of the cast, and the
type actually returned.
In fact, dlsym() is defined by the POSIX standard in a way
that it is designed exclusively for "extern C" definitions
(i.e., unmangled symbols). Since the name mangling of C++ is
implementation-defined and one usually cannot directly get at
the mangled name, you cannot directly (and portably!) load C++
symbols, period.
In fact, dlsym() is defined by the POSIX standard in a way that
it is designed exclusively for data, and not for functions at
all. But since POSIX also requires data pointers and function
pointers to have the same size and representation, it doesn't
matter.
Beyond that, POSIX is completely neutral with regards to what
the returned value points to; the only thing that's important is
that you convert the pointer to whatever type the pointed to
object or function really has in the shared library.
As for name mangling... That's a different issue. In general,
you can't link C++ programs compiled with different compilers,
statically or dynamically. But formally, there's nothing wrong
with passing the mangled name to dlsym. It's just a lot easier
to use ``extern "C"''. (Note that the same considerations apply
to GetProcAddress under Windows.)
What I was referring to as the 'non-standard extension' is the
fact that dlsym returns void*, and to cast void* to a function
pointer is 'illegal' (in the sense that it is *not* covered by
either C++ nor C standards). It is a popular extension, and
one that the POSIX standard requires. But an extension
nonetheless.
The POSIX standard does *not* require it (although as you say,
most Unix compilers do have it). The example in the POSIX
standard doesn't use it; it uses something like:
void (*pf)();
*(void**)(&pf) = dlsym("function");
(Note that in C++, since you're passing an unmangled name, you'd
have to write the first statement:
extern "C" {
void (*pf)();
}
That's false. With both, you can get a pointer to anything.
And if the library contains classes which have been exported
(and under Unix, by default, everything has been exported),
you can new them. But you need a header file with the
concrete type to do so.
GetProcAddress yields in fact a function pointer. To cast this
to an object pointer is just as illegal as the other way round
(like dlsym() requires).
Yes. But the same trick as POSIX requires above can be used in
reverse; both function and data pointers do in fact have the
same size and representation under Windows.
And you are missing my point, actually. Yes, you can return a
pointer to "anything". But that's not good enough for C++'s
"new" to work, since you can only return a pointer to an
instance of some kind (i.e., a function or some kind of
object). Classes are not first-class objects in C++, so you
cannot return the "address of a class" or something like that.
The only symbols that a class generates are its member
functions (in mangled form), and those you cannot just load at
runtime.
But the new operator doesn't require an object for a class. But
yes, I think I missed your point. IIUC, what you're saying is
that you can't use dlsym directly to obtain a newed object.
Which is correct: of necessity, it returns the address of
something that has static lifetime (in the sense of the
standard).
--
James Kanze