Re: passing a string to a dll
"SteveR" <srussell@removethisinnernet.net> wrote in message
news:OIsWUtm%23HHA.5160@TK2MSFTNGP05.phx.gbl...
These comments about LPCTSTR in the DLL, how much do they apply to a
shared DLL? Not that mine is necessarily going to be shared, but that's
the type I chose by default when I created it. Is this also about
overhead? Should I avoid C++ as much as possible inside the DLL?
If the parameter is a CString (or pointer or reference to CString) then any
exe that wants to use the DLL must use MFC. A lot of things can go wrong
passing "smart" objects into a DLL. It can work but the build settings for
exe and DLL have to be just right.
But LPCTSTR is not a "smart" object. It is not even C++. It is a simply a
pointer to char or wchar_t. This kind of parameter makes the DLL usable
from C.
Using LPCTSTR is not really about overhead, it is about K.I.S.S. It avoids
all the potential issues with passing objects
If I move these strings into the DLL function, I will be happy to get them
out of the exe; but what impact does this have on performance, memory
consumption or anything else? Am I gaining or losing anything?
The only performance loss caused by a DLL is the extra program startup time
needed to load the DLL. Once it has been loaded into memory there is no
significant difference between calling a function in the exe and calling a
function in the DLL.
And if I move the alphanumeric code array to the DLL as I intend, how do I
build the array with LPCTSTR instead of CString?
In the exe, no change. You can pass a CString to an LPCTSTR parameter.
In the DLL, you would assign the LPCTSTR to a CString.