Board index » cppbuilder » Wait a second! [out] & SysAllocString() vs. Detatch()?

Wait a second! [out] & SysAllocString() vs. Detatch()?


2004-02-13 10:03:31 AM
cppbuilder13
In this group on Jan 16th, I asked about the correct way to handle memory
for [out] string paramaters. (See: "How to handle memory of [out] strings?")
I got immediate excellent feedback from two great reliable sources (Remy and
Alan B.) which essentially said the same thing: Use SysAllocString() in the
COM server and the client must use SysFreeString() when done. As in the
following:
// server
HRESULT foo(BSTR* RetVal)
{
*RetVal = SysAllocString(L"Hello world");
return S_OK;
}
// client
BSTR RetVal = 0;
server->foo(&RetVal);
// do something with result if not still 0
SysFreeString(RetVal);
Great - BUT - In my bible: "C++ Builder 6 Developers Guide, Hollingworth,
Swart et. al." I stumbled accross a completely different method in the
section discussing DCOM. (If you have the book its chapter 18, pages
724-727)
The method is:
// server
HRESULT foo(BSTR* RetVal)
{
WideString strValue = "Hello World";
*RetVal = strValue.Detach();
return S_OK;
}
//client
WideString strValue;
serverObj->foo(&strValue);
// do stuff and forget about strValue - no need to explictly free it.
This seems much cleaner and simpler requiring less WinAPI. I would prefer
it unless of course the learned authors of that book are wrong and are
leaking memory. Can anyone shed some light here? I am particularly
interested since some of my clients use VB and have to go to extra trouble
to get at the SysFreeString method.
Thanx again.
M.
 
 

Re:Wait a second! [out] & SysAllocString() vs. Detatch()?

"Marcus P." < XXXX@XXXXX.COM >wrote in message
Quote
Great - BUT - In my bible: "C++ Builder 6 Developers Guide,
Hollingworth, Swart et. al." I stumbled accross a completely different
method in the section discussing DCOM.
The approach is the exact same as far as the COM API is concerned.
WideString is just a VCL wrapper for BSTR and calls SysAllocString() and
SysFreeString() internally.
Quote
This seems much cleaner and simpler requiring less WinAPI.
Only as far as your own code is concerned. However, the same API functions
are being called whether you use WideString or manage the BSTR manually.
Quote
I would prefer it unless of course the learned authors of that
book are wrong and are leaking memory.
They are not. What they suggested works fine. It is just a more VCL
approach to an otherwise API-oriented issue.
Quote
I am particularly interested since some of my clients use
VB and have to go to extra trouble to get at the
SysFreeString method.
They will still have to do that anyway. What you decide to do on your
server-side coding has no effect on the client-side coding, as long as you
stick to the rules of COM in general.
With that said - VB wraps everything in Variant to begin with, and Variant
has native support for containing and managing BSTR values (well, VB hides
the details about it, anyway). So, if you have a method like the following
in your COM server in C++:
HRESULT TMyObject::foo(BSTR* RetVal /*[out, retval]*/)
{
*RetVal = WideString("Hello World").Detach();
return S_OK;
}
The VB client can simply do the following:
obj = CreateObject("whatever")
str = obj.foo
And that is all that should be needed.
Gambit