Ой ребята, ой не могу, посмотрите на картинку с Builder 6

void __fastcall TForm2::BitBtn1Click(TObject *Sender)
{
if (!checkfill(editline))
   {
   if (Application->MessageBoxA("блаблабла?","блабла!",MB_YESNO)==IDNO)
      {return;}
   }
fillrecord(editline);
Form2->Close();
}
//---------------------------------------------------------------------------
void __fastcall TForm2::BitBtn2Click(TObject *Sender)
{
if (!checkfill(editline))
    {
    if (Application->MessageBoxA("блаблабла?","блабла!",MB_YESNO)==IDNO)
       {return;}
    }
fillrecord(editline);
findempty();
Label4->Caption=editline;
fill();  // очистка
}

Ну так вот, fillrecord(editline); в первой функции не трассируется по дебюгеру!
Что я только не делал (переносил строки, по новой переписывал, перегружался от греха), все равно во второй функции трассируется, в первой которая по сути логики та-же самая, все равно нет. В чем дело?, может кто скажет как такое побороть? Хотя сомневаюсь что кто-то сталкивался, сам впервые за энное лет вижу. А проект уже завтра сдавать.

Дмитрий.

Здравствуйте, <Аноним>, Вы писали:

А>Ой ребята, ой не могу, посмотрите на картинку с Builder 6

А>

А>void __fastcall TForm2::BitBtn1Click(TObject *Sender)
А><skipped>
А>fillrecord(editline);
А>Form2->Close();
А>}
А>//---------------------------------------------------------------------------
А>void __fastcall TForm2::BitBtn2Click(TObject *Sender)
А><skipped>
А>fillrecord(editline);
А>findempty();
А>Label4->Caption=editline;
А>fill();  // очистка
А>}
А>

ИМХО, компилятор при оптимизации в первом случае просто выбрасывает fillrecord(editline); за ненадобностью, т.к. результаты выполнения функции нигде не используются, как и editline.

Во втором случае есть использование: Label4->Caption=editline;. Если в первую процедуру добавить перед закрытием формы обращение к editline (for.ex. MessageBox(..editline..)), то всё должно пройти как положено.

Здравствуйте, _spin_, Вы писали:


__>ИМХО, компилятор при оптимизации в первом случае просто выбрасывает fillrecord(editline); за ненадобностью, т.к. результаты выполнения функции нигде не используются, как и editline.

__>Во втором случае есть использование: Label4->Caption=editline;. Если в первую процедуру добавить перед закрытием формы обращение к editline (for.ex. MessageBox(..editline..)), то всё должно пройти как положено.

Не знаю с чего вы взяли такие выкладки, ведь судя по листингу editline это переменная, в моем случае глобальная. Вначале она объявлена как extern int. Так что по любому компилятор должен вызывать функцию fillrecord(editline);

Или я разучился сегодня писать или что-то без меня в мире случилось с С++. На кой черт ему оптимизировать (компилятору) явный вызов функции с параметром явно определенной переменной хоть и объявленной как extern
В любом случае спасибо. Ваш совет на самом деле работает. Хотя хоть тресни не пойму почему мой вариант не пашет.

Здравствуйте, _admin_, Вы писали:

Короче сам-же и отвечаю:
__>В любом случае спасибо. Ваш совет на самом деле работает. Хотя хоть тресни не пойму почему мой вариант не пашет.

Несмотря на то что трассировка (точка) появляется, на самом деле в вызове

void __fastcall TForm2::BitBtn1Click(TObject *Sender)

ни один breakpoint не работает!

Вылечилось тем что пришлось прибить кнопку на форме, сохраниться и завести новую кнопку.
После этого заработало но опять же криво. Функция fillrecord(editline); вызывается, но в Буилдере трассировка на эту функцию опять-же не показывается. Может переустановка поможет. Потом разберусь.


Дмитрий.

Здравствуйте, _admin_, Вы писали:

__>В любом случае спасибо. Ваш совет на самом деле работает. Хотя хоть тресни не пойму почему мой вариант не пашет.

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

В Вашем случае возможен следующий вариант:

Построив алгоритм выполнения программы, компилятор обнаружил, что вызов данной функции не влияет на ход выполнения программы, а значит его можно удалить. Т.е. имеет место либо "тупиковая ветвь" алгоритма, либо незначащий промежуточный шаг (типа {s = s + 1; s = s — 1;} ).

Здравствуйте, _admin_, Вы писали:

Учи олбанцкий. Тут тебе не родное ПТУ чтобы такие заголовки писать

Здравствуйте, _admin_, Вы писали:

__>Здравствуйте, _spin_, Вы писали:


__>В любом случае спасибо. Ваш совет на самом деле работает.

Рано я порадовался глядя на компилятор и видя в нем точку трассировки. НЕ РАБОТАЕТ.
А вот и причина, описываю детально.
fillrecord(editline); не может и не должна оптимизироваться (я то знаю что говорю) так как эта функция делает очень многое. Была всетаки Бага компилятора. Пришлось перебить сами кнопки на форме BitBatton и все стало на место.
Спасибо всем откликнувшимся

Ну-ну
А не проще было бы прописать случайно удалённый обработчик события Click для кнопки BitBtn1?

Здравствуйте, ArtDenis, Вы писали:

AD>А не проще было бы

Не проще. Ведь тогда не вскрылась бы такая ужасная бага компилятора!

Здравствуйте, kavlad, Вы писали:

K>Здравствуйте, ArtDenis, Вы писали:

AD>>А не проще было бы

K>Не проще. Ведь тогда не вскрылась бы такая ужасная бага компилятора!
K>

Прежде чем наезжать и писать подобное почитайте первые топики.
Писал: в обработчике кнопки при трассировке дебугером нет точки трассировки только на вызове некой функции.
Следовательно обработчик существует. Что непонятного?