У меня такая ситуация сложилась...
У меня есть коллекция объектов (тип CObArray ) моего типа CVarItem.
В процессе работы программы я добавляю в него новые объекты:

Код

CVarItem* pItem = new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]);         m_arrVarList.Add(pItem);

Вот только при этом получаются бешеные утечки памяти, потому что я ее не освобождаю.
Если освобождаю:

Код

CVarItem* pItem = new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]);         m_arrVarList.Add(pItem);         delete pItem;

то вылетаю с exception 0xC0000005: Access violation reading location 0xfeeefeee.
Ничего не могу понять, я что, лезу куда-то не туда в память??
Полный код функции вот:

Код

void CanalyserApp::GetVarsFromInit(CString strVars, VARSTATE state, int iLine, char lpszType[10], CString strSubProgName ) {     int iStart = 0;     char szTokens[] = _T(" ,\n\t\r:");     CString strToken = strVars.Tokenize(szTokens, iStart);     while( strToken != "" )     {         CVarItem* pItem = new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]);         m_arrVarList.Add(pItem);         strToken = strVars.Tokenize(szTokens, iStart);     }     }

Цитата(kometa_triatlon @ 25.11.2005, 23:49)

Если освобождаю: то вылетаю с exception 0xC0000005: Access violation reading location 0xfeeefeee. Ничего не могу понять, я что, лезу куда-то не туда в память??

Цитата(kometa_triatlon @ 25.11.2005, 23:49)

У меня есть коллекция объектов (тип CObArray ) моего типа CVarItem.

Замени на CPtrArray, только не забуть потом удалить эти обьекты (когда они уже будут не нужны)

Mad
Заменил, то же самое ....

kometa_triatlon
А тебе обязательно нужен дву-направленный список ? (просто на практике почти всегда удаеться обойтись одно-направленным)

если нет, то попробуй просто написать свой контейнер для хранения (я лично вообще не использую контейнеры из MFC ), а то определить что происходит внутри MFCшного кода довольно трудно (на практике легче написать свой, пусть и не такой универсальный, зато легко отлаживать, и болле оптимизированный )

В списке ты хранишь не обьекты, а указатели на них. Освобождаешь память - указатели указывают в никуда, отсюда и ехсепшины. Для освобождения памяти добавь процедурку

Код

FreeAll(CPtrArray &pa) {    pa.FreeExtra();    for(int i=0;i<pa.GetSize();i++)    {        delete pa[i];    }    pa.RemoveAll(); }

Почистит весь список

Это сообщение отредактировал(а) threef - 26.11.2005, 09:43

Цитата(kometa_triatlon @ 26.11.2005, 00:49)

CVarItem* pItem = new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]);         m_arrVarList.Add(pItem);

Это зачем? Сделай так:

Код

m_arrVarList.Add(new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]));

и все будет работать

AlexPro

Цитата(kometa_triatlon @ 25.11.2005, 23:49)

CVarItem* pItem = new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]);         m_arrVarList.Add(pItem);

и

Цитата(AlexPro @ 26.11.2005, 11:17)

m_arrVarList.Add(new CVarItem(lpszType, strToken, strSubProgName, iLine, state, m_arrStrCode[iLine]));

в сути одно и тоже, только в первом случае ты сам определяеш локальную переменную класса, а во втором это делает за тебя компилятор

Некоторые не поняли наверное вопроса
Мне не нужно удалять список.
Я получил в процессе работы некоторые данные. Теперь хочу добавить их в коллекцию. Я создаю динамически новый объект, загоняю в него данные, потом этот объект добавляю в коллекцию.
Я думал, что сама инфа заносится в коллекцию и я могу удалять объект.
Получается, сам контейнер не хранит информацию, а лишь указывает на нее?
Как мне лучше обойти это?
Создать какой-то дежурный объект моего класса, каждый раз при занесении новой информации изменять данные в нем и потом заносить?

Цитата(kometa_triatlon @ 26.11.2005, 15:49)

Теперь хочу добавить их в коллекцию. Я создаю динамически новый объект, загоняю в него данные, потом этот объект добавляю в коллекцию. Я думал, что сама инфа заносится в коллекцию и я могу удалять объект.

Коллекция (вообщето если точно то контейнер) хранит или указатели на обьекты, или ссылки на одьекты, Самиже обьекты контейнеры не хранят.

Цитата(kometa_triatlon @ 26.11.2005, 15:49)

Как мне лучше обойти это?

А как ты хочеш хранить информацию, и при этом не занимать память ;)
Что-бы минимизировать использование памяти, храни указатели на обьекты класса, хранящии информацию
Можно еще хранить данные не в классе, а в структуре (расход памяти еще снизиться, а контейнеру до лампочки на что указатель)

Цитата

храни указатели на обьекты класса, хранящии информацию

Я так и делаю)

Интересно, а как же мне тогда освободить память?
После завершения вывода результатов вызвать что-то типа:

Код

FreeAll(CPtrArray &pa) {    pa.FreeExtra();    for(int i=0;i<pa.GetSize();i++)    {        delete pa[i];    }    pa.RemoveAll(); }

?

Кстати, я пробовал так сделать, но вылетел с exception

Обрисую ситуацию: Есть диалоговое приложение, которое использует функции из DLL.
В библиотеку я передаю строку, обратно получаю указатель на СPtrArray
У меня два таких контейнера: один в классе диалога, другой в классе библиотеки, я сначала заполняю библиотечный, потом возвращаю указатель на него клиенту:

Код

m_arrVarList.Copy( *Run(strCode, m_iLineCount));

Run - функция из dll.
Вот не пойму, как освободить память... Если я уже в самом конце работы после выведения данных из контейнера пытаюсь его (тот, который в классе диалога) удалить в цикле (см. выше) , то вылетаю

Добавлено @ 03:07
Есть все-таки MFC-контейнеры, которые хранят информацию, а не указатели? Может быть CObList?

Цитата(kometa_triatlon @ 27.11.2005, 02:04)

Есть все-таки MFC-контейнеры, которые хранят информацию, а не указатели? Может быть CObList?

Он хранить только ссылки на обьекты класса.

Цитата(kometa_triatlon @ 27.11.2005, 02:04)

m_arrVarList.Copy( *Run(strCode, m_iLineCount));

есть более простой способ (и использование памяти меньше )

Код

// в классе диалога CSomeDataClass *pData; int iDataElementsCount; void FillArray() {     iDataElementsCount = Run(strCode, m_iLineCount, &pData); } CSomeDataClass* GetDataElement(int index) {     return pData[index]; } void FreeArray() {     for(int i=0; i<iDataElementsCount; i++)         delete pData[i];     delete pData; } // в DLLке int Run(CString strCode, int m_iLineCount, CSomeDataClass **pArray) {     pArray = new char[sizeof(void*)*k]; // k - кол-во возвращяемых элементов     for() // или while     {         ...         pArray[i] = new CSomeDataClass();     } }

Могут быть какието ошибки (писал прямо тут, и компилить не пробывал ), но общий принцип должен быть понятен.

Кстати сам CPtrArray примерно так и работает, просто в него добавленно еще целаю куча разных ассертов, и возможностей

Обрати внимание именно на

Цитата

int Run(CString strCode, int m_iLineCount, CSomeDataClass **pArray)

**pArray

Если ты хочешь вернуть распределенный массив из функции, то ты должен передавать не массив(*pArray), а ссылку на него(**pArray).

Кроме того, есть шаблонные классы, способные спокойно хранить обьекты а не ссылки на них:
CArray <itemType,itemType>MyArray;
CList <itemType,itemType>MyList;
Только учти, что хранятся КОПИИ обьектов,так что в случае распределения ресурсов в самом обьекте необходимо предусмотреть все в конструкторе копирования. Или храни указатели.

Цитата

Кстати, я пробовал так сделать, но вылетел с exception

Посмотри, что за ехсепшн, где он возникает

Цитата

Можно еще хранить данные не в классе, а в структуре (расход памяти еще снизиться

Не сильно доверяй этому утверждению, расход памяти не зависит от того, структура это или класс. С точки зрения C++ это равнозначно, различия только в доступе по умолчанию.

Это сообщение отредактировал(а) threef - 28.11.2005, 11:21

Цитата(Mad @ 26.11.2005, 19:31)

Самиже обьекты контейнеры не хранят.

Расскажи об этом вектору, листу, мапу...
А то они этого не знает, и каждый раз в себя копируют объекты, подлецы((

Mad
А что, хороший способ, действительно мог бы и додуматься передавать мой контейнер в функцию из библиотеки, чем копировать...

Neitron
Давно мне, бездельнику, пора бы выучить STL...

threef

Цитата

Не сильно доверяй этому утверждению,

Я и не доверяю

ОК, кое-какие идеи появились, будем реализовывать...