* 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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
