does shared_ptr release memory?

Started by
17 comments, last by SiCrane 18 years, 8 months ago
The value that I get out of it. is errornous chars
If you insist on saying "DUH", try to make a post that makes a little more sense
Advertisement
std::string * pointer_to_value = & strValue;


If you are using this line and strValue goes out of scope (ie. the function returns) pointer_to_value will likely point to garbage. You should use the pointer to the value stored in the vector assuming that the vector is still in scope.

Using smart pointers the way you were before is more cumbersom but safer if you're using it for the right reasons. If you hold the shared_ptr somewhere else in your program and the vector is destroyed you are guaranteed that the pointer still points to valid data.

Besides those facts, I think it's funny that the first suggestion was to move away from the safer way of doing things. :D Of course, you shouldn't use shared_ptr unless you need it.
Quote:Original post by snk_kid
Quote:Original post by cptrnet
The value that I get out of it. is errornous chars


Well that is not surprising if you are giving the address through std::basic_string::c_str of a local variable, since you are passing the string by value (which is already one redundant copy) and then make another copy in the vector, they are not the same instance.

Pass the parameters by constant reference, then push into vector, then call std::basic_string::c_str through vector and not the function parameter ones.


The Win32 API dosn't copy the string when it inserts it into a list control? That would be the problem! This would be used in that case: SendMessage(m_hControl, LB_SETITEMDATA, (WPARAM)iSize, (LPARAM)m_Values[iSize].c_str());

(also, iSize should be renamed to iIndex or something like that - it's a misdominer to call it the size.

Quote:Besides those facts, I think it's funny that the first suggestion was to move away from the safer way of doing things. :D Of course, you shouldn't use shared_ptr unless you need it.


It is ironic that our suggestions are adding bugs instead of removing them :-). It's entirely possible, actually, that boost::shared_ptr will provide a speed benifit here, due to the less string-value copying we do. Only a profiler would tell for certain, one way or another. Actually, scratch that striked bit, for this case :-). My caffinee has made me gittery but no more alert, forgive me :-(.
Quote:Original post by MaulingMonkey
The Win32 API dosn't copy the string when it inserts it into a list control?


I'm assuming that is the case because of the results he is getting.
Quote:Original post by snk_kid
Quote:Original post by MaulingMonkey
The Win32 API dosn't copy the string when it inserts it into a list control?


I'm assuming that is the case because of the results he is getting.


Well, I don't use the Win32 API on principle, so I certainly wouldn't know, but that would explain things :-).
I might be wrong, it might actually do a copy, he might be giving it the wrong message like it should be LB_ADDSTRING or something i don't know, i don't do or care for GUIs with win32 to nasty [wink]
It does do a copy. The Win32 API isn't that user unfriendly.
The string will be copied, but it'll be copied when the message is received, not when it's sent. I'm no expert on win32 and it's message queues, but I think it may be safe to assume there's a possibility of a threaded delay between the message being sent and it being received.

Enigma
SendMessage() only returns after the message is processed.

This topic is closed to new replies.

Advertisement