|
How do you expect STL components to magically delete themselves ? Cleaning up after themselves is what C++ classes have destructors for.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: How do you expect STL components to magically delete themselves ?
He probably read somwhere that he need not learn the basics but jump right into STL programming. 
|
|
|
|
|
say u have vector<string*> in such case the vector will delete the pointers but the memory referred by the pointers.So it leads to memory leak
never say die
|
|
|
|
|
If you have a vector of pointers to dynamically created objects, you must explicitly delete those objects before the vector goes out of scope:
using std::wcout;
using std::endl;
using std::vector;
class Foo
{
public:
Foo(int index) : m_index(index)
{
wcout << L"Creating Foo #" << m_index << endl;
}
~Foo()
{
wcout << L"Destroying Foo #" << m_index << endl;
}
private:
int m_index;
};
int _tmain(int argc, _TCHAR* argv[])
{
vector<Foo*> pFooList;
for (int i = 0; i < 10; ++i)
{
pFooList.push_back(new Foo(i));
}
for (int i = 0; i < 10; ++i)
{
delete pFooList[i];
}
return 0;
}
-- modified at 0:01 Saturday 12th August, 2006
|
|
|
|
|
<br />
Use auto_ptr<> will delete them for you<br />
#include <memory><br />
<br />
using std::wcout;<br />
using std::endl;<br />
using std::vector;<br />
<br />
class Foo<br />
{<br />
public:<br />
Foo(int index) : m_index(index)<br />
{<br />
wcout << L"Creating Foo #" << m_index << endl;<br />
}<br />
<br />
~Foo()<br />
{<br />
wcout << L"Destroying Foo #" << m_index << endl;<br />
}<br />
private:<br />
int m_index;<br />
};<br />
<br />
int _tmain(int argc, _TCHAR* argv[])<br />
{<br />
vector< std::auto_ptr< Foo* > > pFooList;<br />
<br />
for (int i = 0; i < 10; ++i)<br />
{<br />
pFooList.push_back( std::auto_ptr< Foo* >(new Foo(i))); <br />
}<br />
<br />
<br />
<br />
return 0;<br />
}<br />
|
|
|
|
|
Unfortunately, that should not compile! According to the book, "The C++ Standard Library: A Tutorial and Reference" by Nicolai M. Josuttis, I quote:
auto_ptrs don't meet the requirements for container elements.
An auto_ptr does not meet one of the most fundamental requirements for elements of standard containers. That is, after a copy or an assignment of an auto_ptr, source and sink are not equivalent. In fact, when an auto_ptr is assigned or copied, the source auto_ptr gets modified because it transfers its value rather than copying it. So, you should not use an auto_ptr as an element of a standard container. ...
However, boost::shared_ptr can be used with containers! See: http://www.boost.org/libs/smart_ptr/shared_ptr.htm[^]
George
-- modified at 17:52 Thursday 17th August, 2006
|
|
|
|
|
#include <iostream>
#include <vector>
#include <boost/shared_ptr.hpp>
using std::wcout;
using std::endl;
using std::vector;
using boost::shared_ptr;
class Foo
{
public:
Foo(int index) : m_index(index)
{
wcout << L"Creating Foo #" << m_index << endl;
}
~Foo()
{
wcout << L"Destroying Foo #" << m_index << endl;
}
private:
int m_index;
};
int _tmain(int argc, _TCHAR* argv[])
{
vector< shared_ptr<Foo> > pFooList2;
for (int i = 0; i < 10; ++i)
{
shared_ptr<Foo> sptr(new Foo(i));
pFooList2.push_back(sptr);
}
return 0;
}
|
|
|
|
|
dfields326 wrote: Use auto_ptr<> will delete them for you
Containers of auto_ptr's is a BIG No-No! It will compile on some older compilers, but it will not do anything close to what you expect it to. It won't even compile on newer compilers.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
sawerr wrote: But i know that we don't need to delete stl componenets
I don't think you quite understand C++ fundamentals. STL classes (string, vector, list, map, etc) all allocate memory on the heap to store whatever data you are throwing at them. string, for example, allocates an array of characters. As you fill up that array, it evaluates if it needs to allocate a bigger buffer, etc. All that is handled for you. The destructor cleans up that heap memory.
When you write:
void f()
{
string s;
}
s is allocated on the stack. At the end of the scope (in this case, when the function returns), s's destructor is called, which cleans up anything s had allocated.
If you were to write this:
void f()
{
string* s = new string;
}
you would have a memory leak (not good!).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Hi all,
I'm writing an ActiveX ctrl in which a DDE server resides. The DDE server has it's own thread. From that thread function calls are made to the main thread on behalf of some messages. For the processing of one particular message a JavaScript function on the web page must be called. This involves acquiring an IHTMLWindow2 interface. My problem is that I get a return value of E_UNEXPECTED whenever I call the interface querying functions from the DDE server's thread. For example.
hr = m_spClientSite->GetContainer(&spContainer);
I presume this is a threading issue as the method works fine in the main thread. However, I have little idea of how to resolve the situation.
Thanks in advance
Tom
The greatest hinderence to the truth is not ignorance, it is the illusion of knowledge.
Anon.
|
|
|
|
|
I am debugging a large ATL-based application, and am suffering from some memory leaks that are reported when the app exits (thanks to _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF|_CRTDBG_ALLOC_MEM_DF) in the satrtup code). However, unlike MFC apps (which used the DEBUG_NEW macro) the file name/line number of the relevant allocation calls are not displayed. 
How can I find out where the leaks are coming from without paying $$$ for BoundsChecker/Purify - am amazed that ATL doesn't support this.
|
|
|
|
|
|
Thanks Michael. Would this be safe to use in stdafx.h do you know?
|
|
|
|
|
|
If unsure, always put stuff like that after your system includes, but before your own. 
--
Behold, for I am THE CORRUPTOR!
|
|
|
|
|
Robert - what I often find to work quite nicely (without redefining 'new', which for some reason, I find slightly distaasteful - don't ask me why, probably a symptom of incipient OCD) is to use the allocation ID - add _crtBreakAlloc to a watch window, then set it to the ID of a leaking allocation. You'll then break within the debug malloc (actually in _heap_alloc_dbg) when that allocation is made, so have access to the full call stack etc.
<code>
Detected memory leaks!
Dumping objects ->
{53} normal block at 0x002F3CF8, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete.</code>
In this object dump, I have one leaked allocation, with ID 53. So, step into main for your app, then set _crtBreakAlloc to (decimal) 53 and run until you get a User Breakpoint exception dialog appearing. Press 'Break' and there you are! Last modified: 08 August 2006 02:21:44 --
|
|
|
|
|
Excellent - I assume this means the allocation IDs are reused between executions? If so, this is a great tip Stuart. Thanks.
|
|
|
|
|
Yes, and they stay the same, so long as the allocation pattern doesn't change (which is likely to be the case if you don't alter your code too much).
|
|
|
|
|
Hi All,
Anyone of you know how to use the FileMaker Pro Software to develop an ERP system?
Thanks.
|
|
|
|
|
What does ATL/WTL/STL have to do with it?
S o h a i l K a d i w a l a
modified 21-Apr-21 21:01pm.
|
|
|
|
|
Hi
I am new to stl.
I see that we don't need to delete our containers
For example:
vector <char> vec;
But why?
Here, Does vec allocate in heap or stack by default.I heard that Although we don't create vec without new , it is allocated in heap and automatically delete it.Is this true?
If true i tried this:
vector <char>* vec = new vector<char>;
delete vec;
it doesn't give me error.Here this mustn't work.Am i wrong?
I looked to google, there are so many things about stl but i can't find explanation about relationship between stl containers and heap,stack allocation(or new ,delete).In what circumstances are stl containers allocated in heap or stack.And In what circumstances do we need to delete our containers?
Can you please explain me.
Thanks...
|
|
|
|
|
It's basic C++.
class X {
int* p;
public:
X() : p(new int[100]) { }
~X() { delete [] p; }
};
void function() {
X x;
}x is an object allocated in the stackframe of function. X::p however is allocated on the heap, as it's done so by new. std::vector is no different.
--
Simulcast on Crazy People's Fillings
|
|
|
|
|
|
Have a look at the tutorials on this site.
Typically you just declare the STL containers on the stack.
vector<int> vec;
vector<MyClass> vec;
You can add simple types and objects to the vector and you don't need to worry about memory management <i>unless </i>those individual simple types or objects were themselves dynamically allocated.
Kevin
|
|
|
|
|
template <typename T>
struct Deleter { void operator(T* pObj) { delete pObj; } };
template <typename Collection>
void DeleteAllObjects(Collection& coll)
{
std::for_each(coll.begin(), coll.end(), Deleter<Collection::value_type>());
coll.clear();
};
--
Based on a True Story
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
