Ошибка при удалении переменных (delete)

[djan]

Есть такой код, который при удалении выделенной памяти вызывает ошибку DAMAGE: after Normal block (#167) at 0x0032B210:

Код:

bool stopSearch=false;
_node Item;
Item.begin=0;
Item.end=0;
Item.contentLength=0;
Item.content=0;
static UINT arr;

while (!stopSearch)
{
	if ((Item.begin=GetFirstStrPosAfter(fileArray,_T("<item "),Item.end))!=-1)
	{
		if ((Item.end=GetFirstStrPosAfter(fileArray,_T("</item"),Item.begin))!=-1)
		{
			Item.contentLength=Item.end-Item.begin+7;
			arr=Item.contentLength;
			//Item.content = new TCHAR [Item.contentLength];
			Item.content = new TCHAR [arr];
			memcpy(Item.content, &fileArray[Item.begin], Item.contentLength);
			Item.content[Item.contentLength]=0x00;
		}

////////разбор//////////////////////////////////////////////////////////////////////////////
		
///////////////////////////////////////////////////////////////////////////////////////////
		delete Item.content;
		Item.contentLength=0;
	}
	else
	{
		stopSearch=true;
	}
}

_node объявлена как:

Код:

struct _node
{
	UINT  begin;
	UINT  end;
	TCHAR *content;
	UINT contentLength;
};

пишу на VS 2003. При удалени delete Item.content отладчик пишет ошибку. Где она?

[RXL]

djan, классическая ошибка: выделяется массив и след. удалять нужно командой delete[] !

[djan]

Никакого эффекта.
Что delete [] Item.content; что delete Item.content;

[Scorp__)]

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

Код:

Item.content[Item.contentLength]=0x00;

А массив-то с нуля адресуется. То есть выделяешь contentLength элементов, последний будет с номером (contentLength - 1).

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

[Джон]

Ошибка ещё "классическей"



djan,  ты создаёшь буфер размером Item.contentLength например 20, а потом спокойненько эдак обращаешься к 21му элементу!!!

Item.content[Item.contentLength]=0x00;

И привет! Хаккеры, добро пожаловать в переполнение буфера.

зы Scorp__) опередил 

ИМХО Item.content = new TCHAR [arr+1]; - спасёт отца русской демократии

зы зы да и кстати удалять всё-таки лучше с delete []

[Антон (LogRus)]

Кстати собирал версию Debug или Release в релизе ты могбы запросто получить ошибку доступа(а мог и неполучить что еще страшней), дебажная CRT имеет привычку веделять на 1-2 элемента больше занося туда специальные байтики которые она проверит при удалении и ежли ты их по портил будет орать благим матом, благодаря этой фишке находил несколько раз ошибки подобные этой
CRT также контролирует объекты созданные на стеке.

[Scorp__)]

LogRus, а это и произошло Дебажная CRT как раз сказала что-то вроде "смотри куда лезешь!". Релизная это пропускает в половине случаев.

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

[Джон]

Тут ещё всё зависит от того, что будет стоять в памяти после выделенного блока. Если например повезёт (не в данном случае) и дальше будет "твой" же блок, например целочисленный, то в релизе будет всё работать. Ну конечно значение целого числа будет неправильным.

[Антон (LogRus)]

А проблемы от чего ? от того что код больше похож на C чем на C++
есть же вектора/итераторы/std::copy операторы = и конструкторы из других типов

если бы content заменили просто на vector<char> или std::string проблемы бы не было, почти на верняка
у вектора и строки всегда можно спросить длинну
вот это

Код:

			Item.content = new TCHAR [arr];
			memcpy(Item.content, &fileArray[Item.begin], Item.contentLength);
			Item.content[Item.contentLength]=0x00;

я бы заменил на

Код:

std::copy(&fileArray[Item.begin],&fileArray[Item.end],std::back_inserter(Item.content));
Item.content.push_back(0);

если тебе нужна строка в контенте, то так

Код:

Item.content.append(&fileArray[Item.begin],&fileArray[Item.end]);

при этом естественно придерживаемся правила принятого в STL, end это следующий за последним.

[Scorp__)]

LogRus, а это С и есть
Что ж поделать, когда в институте преподают С но под маркой С++. И только позже начинаешь понимать, что это совершенно разные языки. Вот пытаюсь по мере сил переходить на ООП стиль, но вечно надо все сделать "быстро" и времени не хватает использовать новые концепции, в которых к тому же плаваешь. Если честно, то я все никак STL не начну использовать, что уж говорить про BOOST

Потом хочется "все переписать", чтобы было "как надо и универсально, и безопасно", но появляется следующая задача, которую опять надо сделать "быстро". В общем, путь к совершенству бесконечен, но потихоньку пытаемся его преодолеть

[Антон (LogRus)]

осторожно флейм

Scorp__), с институтом понятно, самому стыдно за код написанный в институте. Просто, если ты работаешь программистом на C++, то дешевле делать правильно сразу. Иначе задолбаешься искать/исправлять ошибки, а при достежении определённой сложности код становится не поддерживаемым.

[Джон]

Ок, флейм, но в тему.

ИМХО когда учишься, то тебе предоставлена идеальная возможность узнать всю поднаготную. И потом STL, WTL, MFC etc не будут уже казаться "чёрными коробочками" с удивительными свойствами. Ведь в них используется тот же С или С++.
И это очень здорово, что человек спотыкается на подобные ошибки именно на стадии обучения. Тем больше пользы от них.

[Scorp__)]

LogRus, мне уже стыдно и за кое-что написанное после института Старших товарищей нет, которые правильно пишут, вот и не получается самому быстро освоиться. Но надеюсь, что этот этап все же закончится

Джон, так с этим никто не спорит LogRus и я говорим, что стиль небезопасный и не объектный, на самом деле. И что нужно использовать современные наработки в области программирования. Впрочем, MFC так же написана, в чем я имел несчастье убедиться совсем недавно.

А вообще, совсем отказываться при обучении от структурного программирования нельзя, мало ли где человек будет работать, может он под контроллеры писать ПО будет. Но ошибочно преподавать ООП на базе структурного подхода. Тут еще свою роль играет похожесть внешнего вида С и С++, сразу и не поймешь, что это разные языки. Надо наверное ООП начинать с какого-нибудь Smalltalk или может C# или Java, а потом демонстрировать эти же концепции в других языках.

Ох, что-то флейм рекой потек, соскучились по дискуссиям видимо

[Джон]

Ох, что-то флейм рекой потек, соскучились по дискуссиям видимо

Ну дык, ещё бы! Тем более что это лучше чем про политику. ИМХО. Ну и его в конце беседы подчистить можно. Без проблем.

Я про другое хотел сказать. Речь не идёт о ООП. Я о том, что необходимо понимать что происходит при выделении памяти и какие проблемы могут возникнуть при безалаберном отношении.

В защиту MFC. Не надо забывать, что эта ООП упаковка для API уходящая своими корнями в первые версии винды (кстати afx приставка - это первое название MFC) - те вещи, которая сама программировалась даже не на С++, а на простом С. Так какого строгого ООП вы от неё хотите?

[Scorp__)]

Джон, ну динамической памятью итак всех пугают при обучении Другое дело, что невнимательность все равно делает свое дело.

А по поводу MFC, по-моему это не оправдание, тем более не оправдание для создателей COM. Под интерфейс можно запихнуть всякую бяку, а снаружи все будет красивенько и объектно. К примеру DirectX напрямую работает с видеодрайвером, но разве он от этого становится менее объектным? Другое дело, что надо было заново провести декомпозицию интерфейса ОС, по сути создать интерфейс заново, что весьма трудоемко. Но если бы это было сделано, то винда под MFC выглядела бы объектной. А так как это выполнено сейчас - это лишь попытка (удачная или нет, тут можно спорить) не отстать в технологиях визуального программирования. Внутреннее же устройство классов выглядит так, как будто функции API просто собрали по тематике.

[Джон]

невнимательность все равно делает свое дело.

И это тоже.

А по поводу MFC, по-моему это не оправдание

А я и не оправдываю. Я просто хочу, чтобы люди с пониманием относились. "И не требовали от царя того, что он не в силах сделать." (с) Понимаешь, просто нападки на MFC всегда выглядят так, как если бы он претендовал на идеальность и совершенство. Вот смотри для примера, есть у меня сонька мобильник с 3х мпикс. камерой и Fuji S20 Pro (6Мпикс). Так мобильник делает ну до того хреновые снимки, что на них смотреть не хочется... В сравнении с S20. А кто-то смотрит на них и говорит: "Вау, класс". Я говрю, типа, ну какой же класс? Тут размыто, геометрические искажения, цветопередача фуфло...
А в ответ... Ну дык этож не фотоаппарат, это телефон, который может ещё и фотки делать. И для телефона очень приличные фотки.
Так и с MFC - ну надоело ребятам из мелкософта постоянно кучу хендлов к окошкам сохранять и всё в MainLoop впихивать.
Ну сделали для себя помощника. И всё. А все уже ждут безошибочности и идеальности. Тут ведь закон гор - не нравится не ешь. А коли ешь, то зачем хаить? Достойной альтернативы-то всё-равно нет.

Внутреннее же устройство классов выглядит так, как будто функции API просто собрали по тематике.

Я бы сказал, что это пожалуй самое лучшее определение MFC, отражающее его суть и предназначение. Надо закопирайтить. Именно так и есть. Причём на первом уровне. Нуууу сообщения поглубже спрятали.

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

Что ты имеешь ввиду?

[Scorp__)]

Джон, про попытку я имел в виду противостояние OWL и MFC. Не знаю, если честно, что появилось раньше, но Delphi позволила снизить трудоемкость программирования и требуемую квалификацию в разы. Конечно Майкрософт надо было чем-то отвечать, чтобы не потерять эту часть рынка. Надо сказать, что и время для развития у MFC было: шесть лет где-то ведь или даже больше, явно не врЕменное решение. Причем позиционировалась эта библиотека именно как нечто претендующее на идеальность
То есть как "профессиональный фотоаппарат, который позволит делать вам фотографии неземной красоты, причем без всяких сложностей" Ну мы же знаем этих пиарщиков.

Ну и потом, подход без критики я не приемлю. Это ж можно на что угодно перенести: "да машина плохая, но вы ж на ней ездите вот и нечего хаять", "да фильм дерьмо, но все равно ж мы вам больше ничего не покажем, так зачем ругать". Вообще я стараюсь как можно меньше использовать MFC, использую только каркас для построения интерфейсов. С MFC над программой очень быстро теряешь контроль, поэтому я предпочитаю терять контроль только в интерфейсе, тут уж я не особенно забочусь о безопасности, объектности и проч.

А альтернатива собственно .NET, только мне в ней не нравится рафинированность какая-то. Но для тех целей, для которых предназначался MFC, мне кажется она вполне сойдет.

[Джон]

Ок, тут не получается. MFC "старше" Дельфи. Он разрабатывался ещё под первые версии винды в начале 90х, а у Борланда тогда был только турбо паскаль для винды (не соврать - почему-то вертится на языке - TPWin 1.0) у меня даже где-то ещё дистрибутив валяется, а уже потом его в Дельфи перекрестили. Я сам в то время программил только ан паскале, в большинстве своём под ДОС, тк железа для винды (286, 386) тогда у нас не было. Только кучерявые коммерческие структуры могли ими похвастаться.

А MFC разрабатывалась с целью облегчить жизнь разработчикам софта на С++ под винду. Ни о какой идеальности речи не было. Поэтому и решений было несколько - ATL, WTL. Как говорится кому, что нравилось. Вспомни какой бум был из-за WTL, когда её хоть и без поддержки "опубликовали" в SDK. Все стали переделываться в WTL-программеров, тем более, что названия классов были сходными с MFC. Должен признаться, не минула чаша сия и нашу контору - месяцев 10 делали один проект полностью на WTL, ну и что? Потихонечку всё сошло на НЕТ (каламбур).

Я не говорил, что MFC это временное решение. Это "хоть какое-нибудь" решение, одно из нескольких, которое правда уже держится полтора десятка лет. Но нигде не заявлялось, что MFC это единственно верный и правильный способ программить на С++ под виндой. Визарды в самой студии предлагают кучу других вариантов. НУ а то что MFC чаще выбирают, дык не его вина в этом. Ну чем он виноват, если есть люди, для которых MS Visual Studio является синонимом MFC? Или какой-нить измученный сишными ф-ми программер его обожествил? Говорить-то можно всё что угодно. А доказательств никаких.
А доводка до идеальности мелкософту не выгодна - вещь-то "open source". Мелкософт бы и рад от него отделатся да не может. Вот и пытается чё-нить другое повесить. Или ты можешь так же свободно гулять по исходникам .NET как по MFC?

Насчёт критики. Вещь конечно хорошая. Только когда это действительно критика. Критика с целью изменения, улучшения - это критика. А в отношении MFC? Или ты думаешь тебя услышит сердобольный дяденька Билл и прикажет своим нукерам поднять всё на должный уровень? Так что эта критика больше похожа на брюзжание  старичка по поводу перемены погоды. Ругать можно - изменить нельзя. Так же как и в твоих примерах. Вот пришёл ты кино посмотреть, ты и сам уже понял, что фильм туфта, а рядом сидит эдакий критик и полтора часа "критикует", как будто актёры на экране его услышат и сразу начнут играть лучше. Ну и какой будет твоя реакция?

А .NET, давай будем честными до конца. Пока это только очередная попытка альтернативы. В чём-то удачная, но уж больно высоко ИМХО приподнятая над АПИ, так что гибкость вся сходит на нет. Да и радикальные изменения версий за короткий срок тоже не лучший показатель. Так что я бы пока воздержался от вознесения её на престол. У меня с этим дотнетом как дежавю - уже что-то когда-то было подобное. В общем поживём увидим. ИМХО на этот счёт ещё рано делать какие-то однозначные утверждения.

С MFC над программой очень быстро теряешь контроль

Довольно голословное и ооочень субъективное утверждение. Я программлю с MFC уже лет восемь и ни разу не было такого, чтобы я потерял контроль над программой.

[nikedeforest]

А .NET, давай будем честными до конца. Пока это только очередная попытка альтернативы. В чём-то удачная, но уж больно высоко ИМХО приподнятая над АПИ, так что гибкость вся сходит на нет.

Довольно голословное и ооочень субъективное утверждение.

По конкретнее желательно - где приподнято, на сколько, в чем выражена приподнятость. А то все это общие фразы - приподнятость, гибкость. В такой же манере американцы размышляют о демократии, типо у них она лучше, в России хуже.
з.ы. этой попытки уж восьмой год, а некоторые про нее только слышат. НЕ говорит ли это о косности ума и нежелании дальнейшего развития?

[Джон]

nikedeforest, по поводу цитаты - смотри внимательно там стоит ИМХО. Или ты не знаешь что это означает?

А потом, я на провокации не поддаюсь. Тем более дешёвые. Уже один разговор был в другой теме. Тебе этого мало?
А то ведь допросишься.

зы Кстати, про восьмой год? Это ты какую версию имеешь ввиду? Или ты имеешь ввиду что термину .NET восьмой год?

[nikedeforest]

Если не ошибаюсь в 2000 году .НЕТ первая вышла.
Я знаю, что значит "ИМХО". Просто здесь все сказанное от лица каждого почти всегда является его "ИМХО". Считаю, что все же ИМХО должно быть не голословным, а подкрепленным какими-то фактами или чем-то еще. Ну если нет, так нет, дело ваше.

А потом, я на провокации не поддаюсь. Тем более дешёвые.  Уже один разговор был в другой теме. Тебе этого мало?
А то ведь допросишься.

Раз просьба о конкретике является дешевой провокацией, то мне ничего не остается, как отсутпить. А то видимо и в правду напрошусь.
С уважением.
зы. Кстати хочу отметить, что в связи с нынешним положением дел, Джон чуть ли не единственный, кто правильно пишет, исользуя в своем написание букву "ё". Раньше стандартом являлось замена данной букву на "е", теперь идет обратный процесс. Времена меняются, только и успевай приспосабливаться.

[Алексей++]

дык я тоже ё люблю ) Не только Джон )
У меня ж в фамилии такая буква присутствует, я не могу её игнорировать

[nikedeforest]

В паспорте "е" написана скорее всего?

[Алексей++]

"ё" , однако
кстати, тут столько тяжб с налоговой у людей изза этой несчастной ё, им , видите ли , точность нужна. А человек забыл точки поставить - и началооось

[nikedeforest]

Ёптыть Ж:)

[Scorp__)]

Джон, скажем так, я просто высказал свое мнение относительно MFC, думаю, что на это я имею право И навряд ли я буду критику говорить, что другого фильма мы сейчас все равно не увидим, а значит и этот неплох, по-крайней мере ведь это фильм, а не набор слайдов и он звуковой, и цветной, и даже есть известные актеры, и красивые спецэффекты ; скажу я ему: "Слушай, давай уж посмотрим, если выдержим, но всем расскажем, какая это туфта, и что лучше сюда не ходить". И может быть, в потере контроля над программой можно винить недостаток опыта. Но начинающим я бы не советовал использовать MFC, да и не начинающим тоже...

Да в .NET мне тоже не нравится закрытость исходного кода классов и высокоуровневость. Но важно понимать, что .NET не предназначена для программирования всего, как и любая другая платформа или библиотека. Но с ее использованием делать интерфейсы в разы проще, вот как минимум одно ее преимущество. 

Вердикт: дискуссия себя исчерпала поскольку перешла на совершенно другую тему, еще и похожую на холи вар. Все остались при своем мнении относительно библиотек и общем относительно того, что "учиться надо - это полезно и хорошо"
Джон, если есть возражения по последней части, то я или с ними соглашусь, или подискутируем