LINUX.ORG.RU
Форум — Development  

[C][C++] Есть ли компилятор + отладчик, позволяющий...

 ,


0

0 

void f( int i ) 
{
  int s[MAXLEN]={1};
  for( int j=1; j<MAXLEN; j++ ) {
    s[j+1]=s[j] * i ;
  }
  ...
}

Тут понятно off-by-one error. Сессия может выглядить так:
1. Прога компилиться и запускается, работает как пень 40MHz...
2. Прога автоматически тормозится на строкее s[j+1]=s[j]*j; 
с ошибкой "выход за границы массива"
3. Девелопер дает команду "выйти из блока назад" 
и дебаггер переходит в строку  int s[MAXLEN]={1}; 
восстанавливая все значения (он их запомнил раньше)
4. Девелопер исправляет MAXLEN на MAXLEN-1
5. Это компилируется, прилинковывается, 
но при этом значение i и всех остальных стэковых переменных и кучи 
*не теряется* и проход программы возобновляетя не с начала, 
а с точки int s[MAXLEN]={1};

________________________________________

Где-то такое реализовано (чую, щас лисперы прибегут...) ?

Какова ваша оценка полезности этого в реальной работе ?
← Приложение, требующее большого кол-во одновременных процессов/потоков
uml проэктирование дизайна... →

А исполнять код по мере его написания тебе не нужно? А если понадобится препроцессор тоже откатывать? :)

alexru ★★★★
()
Ответ на: комментарий от alexru

> А исполнять код по мере его написания тебе не нужно?

Исполнять не нужно, а вот на проверять на ошибки в фоне по мере его написания, как это делает K-develop -- нужно.

> А если понадобится препроцессор тоже откатывать? :)

Это вряд ли понадобится, т.к.

1. препроцессор вообще в плюсах редко юзается

2. обычно требуется так продебажить алгоритмы

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

www_linux_org_ru ★★★★★
() автор топика

Это Си. Никто, кроме спец. библиотек и valgrind'a за тебя отлавливать косяки с памятью, не будет. Тем более, в интерактивном режиме.

JackYF ★★★★
()

> Какова ваша оценка полезности этого в реальной работе ?

Бесполезно и в общем случае нереализуемо.

tailgunner ★★★★★
()
Ответ на: комментарий от JackYF

> Это Си. Никто, кроме спец. библиотек и valgrind'a за тебя отлавливать косяки с памятью, не будет. Тем более, в интерактивном режиме.

C тут только для простоты, а я свои косяки буду отлавливать, переопределив оператор [] для шаблона vector.

Вопрос совсем не об том, как отловить косяки с памятью.

ВАМ БЫ ПОМОГЛА ТАКАЯ ИНТЕРАКТИВНОСТЬ? (и она где-то реализована?)

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

> в общем случае нереализуемо.

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

> Бесполезно

Для тебя (это вполне приемлемый ответ)?

Вообще?

www_linux_org_ru ★★★★★
() автор топика

>Какова ваша оценка полезности этого в реальной работе ?

нулевая. ибо указанные условия после generic изменения могут в принципе не наступить, т.е. какого хрена ловить деление на ноль, если ноль в знаменателе не появится в принципе.

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

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

резюмируя: реализовать это геморней, чем отлаживать по-старинке. впрочем, если я таки не прав, реализуй. but you have been warned.

generatorglukoff ★★
()
Ответ на: комментарий от generatorglukoff

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

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

А вот функции в сегменте кода будут другой длины -- тебя это сильно волнует?

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

>> в общем случае нереализуемо.

> Нереализуемо, если и только если программа пишет/читает внешнюю среду.

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

>> Бесполезно

>Для тебя (это вполне приемлемый ответ)?

>Вообще?

Для меня, и, подозреваю, вообще. Ошибка найдена, что еще надо? При этом и "шаг назад" в отладчике, и инкрементальные компиляция/линковка - вещи полезные.

tailgunner ★★★★★
()

> Какова ваша оценка полезности этого в реальной работе ?

практически нулевая.

то что я писал на C обычно завязано на непрерываемый поток данных, например коннекты по сети или даные с датчиков. допустим Вы реализовали эту фишку, откатились на предыдущую строку, но внешний мир то не остановить :) состояние устройства уже изменилось а остановленная прорамма проморгала информационные пакеты об этом изменении и как следствие пошлёт неверную управляющую команду в устройство или клиенту.

Eshkin_kot ★★
()

> Какова ваша оценка полезности этого в реальной работе ?

перекомпиляция - особо не полезно. в visual studio она очень давно кстати есть - edit and continue называется. Ну, компилится быстрее, удобно, но не killer feature.

Настоящий реверсивный дебаггинг, чтоб дебагер запоминал все что программа делала и потом можно было остановиться и взад-вперед листать - ХОЧУ! то что сейчас с gdb делают не то - там сохраняют состояние процесса с помощью fork()... а после каждого шага форкаться не будешь....

gods-little-toy ★★★
()
Ответ на: комментарий от www_linux_org_ru

> 1. препроцессор вообще в плюсах редко юзается
Жесть. А вместо инклюдов в плюсах - либастрал? Не говоря уж об удобных #ifdef 0 и пр. мелочах.

svu ★★★★★
()
Ответ на: комментарий от svu

>> 1. препроцессор вообще в плюсах редко юзается

>Жесть. А вместо инклюдов в плюсах - либастрал? Не говоря уж об удобных #ifdef 0 и пр. мелочах.

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от gods-little-toy

> Настоящий реверсивный дебаггинг, чтоб дебагер запоминал все что программа делала и потом можно было остановиться и взад-вперед листать - ХОЧУ! то что сейчас с gdb делают не то - там сохраняют состояние процесса с помощью fork()... а после каждого шага форкаться не будешь....

Я говорю о том же -- чтобы каждая операция присваивания и копирования запоминала затираемое значение.

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

> Не только. Изменеия в программе могут привести к тому, что сохраненные значения переменных (и стек, и куча) станут невалидными. Что тогда?

В целом -- тогда запрещать такое.

Пример когда все останется валидным:

1. перед редактированием блока кода мы идем назад в точку ровно перед входом в блок.

2. в блоке не описано новых типов данных (так чаще всего и есть)

Возможен еще маловероятный случай, когда в этой функции мы оказались рекурсивно и более того, возврат будет проходить через редактируемый блок. Ну тут видимо надо не позволить редактирование ИЛИ возврат делать на старые версии блока.

> При этом и "шаг назад" в отладчике, и инкрементальные компиляция/линковка - вещи полезные.

Вроде мое предложение это именно от шаг назад, совмещенный с инкрементальной линковкой, но линковкой не целой функции, а только ее блока.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

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

www_linux_org_ru ★★★★★
() автор топика

Посмотри на OCaml и его ocamldebug, там есть команды reverse, backstep и previous.

anonymous
()
Ответ на: комментарий от svu

>Не говоря уж об удобных #ifdef 0 и пр. мелочах.

AFAIK рекоммендации по кодированию GNU рекоммендуют использовать if(0){ } даже в Си. Типо на этапе компиляции-линковки такие ветки отпадают.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> AFAIK рекоммендации по кодированию GNU рекоммендуют использовать if(0){ } даже в Си. Типо на этапе компиляции-линковки такие ветки отпадают.

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

В visual studio частично реализовано (можно править код прям в debug режиме и на ходу его компилить/линковать в запущенный процесс)

Reset ★★★★★
()

>Где-то такое реализовано (чую, щас лисперы прибегут...)
В Common Lisp такое и правда реализовано.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Приложение, требующее большого кол-во одновременных процессов/потоков
Development
uml проэктирование дизайна... →