Re: Does This Leak Memory?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 10/19/04 

Date: Tue, 19 Oct 2004 10:10:31 -0700

I guess it is meant to be called like this:

cpConn->Open(L"whatever", L"user", L"pass", -1);

Then there will be only one set of temporaries on the stack. 

-- 
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam> 
wrote in message news:eRBpRJftEHA.2536@TK2MSFTNGP11.phx.gbl...
> Lawrence Groves wrote:
>> Hi all,
>>
>> A coleague of mine told me something strange about some code of mine
>> that has run for years (not necessarily without error). I pass a
>> string to an ADO connection object's open method, who's prototype is:
>>
>>    inline HRESULT Connection15::Open ( _bstr_t ConnectionString,
>> _bstr_t UserID, _bstr_t Password, long Options )
>>
>> I call the routine like so:
>>
>>    _bstr_t bsConn = "whatever";
>>
>>    cpConn->Open(bsConn, _bstr_t("user"), _bstr_t("pass"), -1);
>>
>> but he says I should do the following to avoid a memory leak:
>>
>>    _bstr_t bsConn = "whatever";
>>
>>    _bstr_t bsUser("user");
>>    _bstr_t bsPass("pass");
>>
>>    cpConn->Open(bsConn, bsUser, bsPass, -1);
>>
>> He claims that the two temporaries in the first case may leak memory.
>> Something to do with the underlying BSTR not being cleaned up properly
>> because of the way the class's copy constructor works.
>>
>> Am I loosing it? It seems to me that the first piece of code would't
>> leak, but I would like a second opinion.
>
> They're both fine, barring any compiler bugs that might cause one to leak. 
> Both require construction and destruction of _bstr_t instances in 
> automatic storage (the stack), so if there's a problem with the _bstr_t 
> class's copy constructor it'll affect both scenarios equally.
>
> The connection function really ought to be declared
>
> Open ( const _bstr_t& ConnectionString, const _bstr_t&  UserID, const 
> _bstr_t&  Password ...
>
> as that would actually eliminate the need to call the copy constructor, 
> but I assume you don't have any control over that (#import generated code, 
> right?).
>
> -cd
>
>

Relevant Pages

  • Re: Does This Leak Memory?
    ... Then there will be only one set of temporaries on the stack. ... Microsoft MVP, MCSD ... >> He claims that the two temporaries in the first case may leak memory. ... > class's copy constructor it'll affect both scenarios equally. ...
    (microsoft.public.vc.atl)
  • Re: Help please with a tricky question
    ... > Turning them into a proper constructor will make it totally impossible ... > to have an uninitialised Stack. ... Stash Implementation ... void Stash::initialise(int sz) ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Why no language improvements?
    ... its not in the win32 compiler. ... the /Win32/ compiler doesn't have stack based objects, ... +AD4- You dont know what a copy constructor is yet you feel compelled to ...
    (borland.public.delphi.non-technical)
  • Re: C++ Object Pointers
    ... requires a copy constructor be defined; if one is not, you can't pass the object by value, ... It pushes the rightmost argument onto the stack, ... >> You pass in a pointer to a variable that is set to NULL. ... >> I don't see how your example of allocating a Base object could possibly ...
    (microsoft.public.vc.mfc)
  • Re: CLR, Value/Ref types, and the thread stack/heap
    ... It comes from the MSIL instructions. ... I4 on the stack. ... Don't confuse the CLR with the C# compiler. ... constructor named in the immediate argument to the 'newobj' instruction. ...
    (microsoft.public.dotnet.framework.clr)