Re: function signature and reference parameter
On 12/2/2010 7:52 AM, Ralf Goertz wrote:
I am writing a library which will be used via dlopen and friends. I
noticed that I can use
extern "C" { //to avoid name mangling
void foo(std::string&s) {
std::cout<<s<<std::endl;
s="bar";
}
}
in the library and
typedef void (*foo_t)(std::string);
Why can't you declare it as accepting a reference as its argument? Is
the mismatch intentional?
foo_t foo = dlysm(handle,"foo");
^^^^^
dlsym, I presume.
in the calling program. Of course if I do so, calling foo(s) in the
calling program doesn't change s. But I had expected a segfault because
the signatures aren't the same.
Signatures do not exist at run-time.
> I assume this works because with my
compiler (g++) foo(std::string) and foo(std::string&) are essentially
the same but if the nonref'd form is used the parameter will be copied
and the function will be called on with the address of the copy instead
of the original.
It "works" because when you declare a function 'extern "C"', the
argument information is removed, doesn't exist. It's up to you to
convert the pointer you get from 'dlsym' to the *correct* one. If you
do not, your program has undefined behavior, most likely. See the
documentation on 'dlsym'.
My questions are: Can I rely on this?
On what, exactly?
> I might want foo to sometimes
change the parameter and sometimes not. On the other hand, dlopen and Co
are C functions. Am I allowed to use references at all or am I just
lucky that it works?
'dlopen and Co' are not "C functions", they are Un!x functions (or
Posix, I don't [care to] remember). Consider asking about them in a
Un!x newsgroup.
The manipulation you perform with your function pointers is akin to the
same for object pointers which you can convert to 'void*' or to the
integral type suitable for that purpose, and then back. For the return
path you use 'static_cast' for the void* or 'reinterpret_cast' for the
integral value. But that is guaranteed to work if you convert to the
proper type as the result. The language provides no guarantees if you
take a pointer to one type, and after the round-trip, so to speak, get
another type. Same with functions. If your original function has a
reference as its argument, the pointer to function needs to have that
exact argument type, or anything can happen (see "nasal demons").
V
--
I do not respond to top-posted replies, please don't ask