При запуске проги возникает ошибка (обнаружена ошибка. Приложение будет закыто …) я нажимаю на (отладка) , запускается Visual Studio 2005 и открывает мне код с Break Point’ом на этой строке :

str объявленна как CString str;
в Debug все отл. Работает !
в чем может быть проблема ?
сорри что не в том разделе !

Это сообщение отредактировал(а) DigitSphinx - 25.5.2007, 22:23

Так вот навскидку не скажу, что именно не так.

Разница между Debug и Release в том, что в Debug все объявленные переменные инициализирутся нулями, а в Release - нет, в них будет находится какой-то мусор. Проверь, есть ли где-то неинициализированные переменные.

Все разобрался !, проблема была в int’овской переменной !
Но теперь я вообще офигел , как в Debug’е работало .
Потому что переменная берется с указателя 
 
при запуске этот указатель пустой,
(в конструкторе явно указанно) 

По этому и вылизала ошибка типа “Access violation”.
а в дебаге он игнорирует ошибку и работает по алгоритму , т.е. фигня !
P.S. Надо поразбираться !
Спасибо Hurricane, может в дебаге и работало потому что он инициализирует переменные нулями !


Это сообщение отредактировал(а) DigitSphinx - 26.5.2007, 00:36

В данном случае это непринципиально, но всё же уточню - не нулями, а фиксированными значениями, чередующимися парами нулей и единиц. Например, для целой переменной это значение 0xCCCCCCCC

то, что значение CC представляет из себя в бинарном виде "11001100", в данном случае не имеет никакого значения. все неинициализированные данные и "охранные зоны" забиваются CC для того, чтобы в случае перехода выполнения на данные, сразу сработало отладочное исключение - int 3, опкод которого и есть CC. 

[немного_оффтоп]

А не проще это сделать через атрибуты секций? Да и вообще очень специфичная ситуация. Разумней было бы забивать данными, более осмысленными с точки зрения данных, а не кода. ИМХО, конечно.
[/немного_оффтоп]

 не совсем понял о каких секциях речь - если о PE, то стек, например, не сопоставляется ни с какими секциями. а основным препятствием является невозможность назначения "правильного" набора атрибутов ввиду их инклюзивности(до появления DEP): PAGE_READONLY и PAGE_READWRITE разрешает выполнение, PAGE_EXECUTE - чтение(к рассматриваемому моменту не относится). т.е. до появления DEP запретить выполнять данные было невозможно.


более осмысленные с точки зрения данных значения(типа 0 или -1) могут скрывать ошибки "неинициализированности", с чем, собственно, и боремся...  а так(CC) - сразу двух зайцев: и отладочное исключение в случае выполнения, и "достаточно мусорное" значение для неинициализированных переменных.

Ну, во-первых DEP существует уже давно. Во-вторых, я в принципе не пойму - будет выброшено int 3 при нашей зверской (и так часто встречающейся  ) попытке выполнения кода локальной переменной. Мы разве сможем что-то толком понять.?


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

Почему же на релиз обычно больше ругаются?  Хотя, если честно у меня почему-то или работает и то, и то (я даже не про VC++ - а вообще). Или не работает ничего. За исключением очень исключительных случаев, когда очень агрессивная оптимизация чтой-то ломала. Но у меня такое было буквально несколько раз. И то при выяснении (ради любопытства) обычно находился в bug notes компилера подобный случай.

Кстати - да, логично. Но почему-то больше запомнились случаи, когда дебаг еще кое-как хромал, а релиз вываливался по эксепшну. Или это просто психологический эффект?

Пытаюсь сообразить, почему я написал про инициализацию нулями. Ничего в голову не приходит    Конечно же, что там не нули (ну, скажем, вперемешку с единичками   ).

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

в дебаге между переменными кладутся "охранные зоны", которые проверяются при выходе из области видимости объявленных переменных: если будет выход за пределы, отладчик будет "ругаться" - заметнее, imho, некуда... 

ps. надо отметить, что все вышесказанное относится к стековым переменным. глобальные заполняются нулями, а члены классов динамически выделенная память - значением CD. почему CD - х3, видимо, надо было как-то отделять мух от котлет...  

Это сообщение отредактировал(а) dumb - 30.5.2007, 11:54

dumb, эти CD, CC - это конкретно к VC++ относится? Я сомневаюсь, что все компилеры следуют столь интуитивно понятным правилам   

 тема вроде как именно о VC и была...


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