passing objects through dll boundary?

[szabi]

Hi!

I have seen in a couple of libraries that object are never passed
through dll boundary, instead the results are returned through an
output parameter reference like:

void f(std::string &s)
{
s = "foo";
}

Why is that? Is it a better contruct?? I find this much cleaner:

std::string f(void)
{
return "foo";
}

Another argument could be that it's not safe to return an object, but I
don't understand why. I checked it under Linux and everything is fine.
Lately I have joined the development of a program written in c++ under
MSVC++ 7.1. This code is in a pretty bad shape, so it may not be
connected, but when I try to return a string through dll boundary it
throws an exception.

Any comments?

Szabi

 

[Alf P. Steinbach]

* szabi:

Hi!

I have seen in a couple of libraries that object are never passed
through dll boundary, instead the results are returned through an
output parameter reference like:

void f(std::string &s)
{
s = "foo";
}

Why is that? Is it a better contruct?? I find this much cleaner:

std::string f(void)
{
return "foo";
}

Another argument could be that it's not safe to return an object, but I
don't understand why. I checked it under Linux and everything is fine.
Lately I have joined the development of a program written in c++ under
MSVC++ 7.1. This code is in a pretty bad shape, so it may not be
connected, but when I try to return a string through dll boundary it
throws an exception.

Any comments?

Standard C++ does not (yet) officially recognize the existence of shared
libraries or DLLs.

So technically your question is off-topic, I guess.

However, since it pertains to real-life application of C++:

With Windows DLLs you are not guaranteed that the DLL and code using
that DLL are emploing the same heap, or, indeed, any other runtime
library state or even the same runtime library. To return a std::string
from a DLL function you need to ensure that, because the std::string is
likely to just contain a pointer to dynamically allocated memory. And
with most tools the way to do that is to use a DLL version of the
runtime library, both in the DLL in question and in the calling code,
and to be very sure it's the same DLL runtime library version.

Generally it's safer to forego the use of C++ classes entirely in a DLL
interface, and to never have allocation responsibility on one side of
the interface and deallocation responsibility on the other side.

 

[benben]

In addition to all sensible replies may I also suggest you define your
"DLL boundary" through (pure) abstract class, including the passing of
arguments. This way all it needs to deal with is just pointers to
abstract base class that does not come with many other implications.

Frankly, this is one of but many plausible solutions. However I found
this way introducing far fewer troubles than the others.

Ben