отладка приложения , отладчик он нужен или нет?

привет чуваки с вами Сифон!
скажите в каких случаях вы используете его ?
лично я его уже давно не использую
точнее я им даже не умею пользоваться, обычно я раскидываю ассерты и трассировочные месседжи и все. в последнее время ещё юзаю тесты типа Гугл.
пс. наверное просто я не писал оочень сложных программ

Сообщение отредактировано: Cfon - 20.02.17, 06:32

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

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

Цитата KILLER @ 20.02.17, 07:47

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

баг это что логическая ошибка?

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

Добавлено 20.02.17, 08:12
Когда-то я и сам недооценивал пользу отладчика.

Цитата Cfon @ 20.02.17, 06:33

я так понимаю что отладчик нужен для трассировки ассемблерного кода

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

Цитата Cfon @ 20.02.17, 03:15

пс. наверное просто я не писал оочень сложных программ

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

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

Цитата Олег М @ 20.02.17, 08:20

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

Почему?

Цитата KILLER @ 20.02.17, 08:27

Почему?

Попробуй поотлаживать программу, где у тебя больше одного потока. Например найти дедлок.

Когда то давно, когда я был маленький и глупый, я все время пользовался отладчиком MSVC, но однажды устроился работать в контору, которая писала под свое кастомное железо, и по каким то причинам ( уже не помню ) gdb было просто не собрать. С тех пор вся моя отладка это вывод в консоль, проблем не знаю никаких. + Как правильно подметили при отладке многопоточных приложений gdb пмомжет чуть менее чем никак ИМХО.

Цитата Painkiller @ 20.02.17, 08:57

Когда то давно, когда я был маленький и глупый, я все время пользовался отладчиком MSVC, но однажды устроился работать в контору,

Да и сама Микрософт не просто пользуется - просто злоупотребляет "OutputDebugString".
Прямо из студии прут часто бессмысленные сообщения.
NVidia тоже не гнушается.. да все практически используют.
А что делать в случае, когда остановить программу невозможно ?
Как посмотреть удалённо, что происходит с программой ?
Или как узнать, что происходит внутри микроконтроллера ?
Как только будут получены ответы на эти вопросы, выяснится, что потребность
в отладчике уже не такая срочная.
---
А если дело дошло до отладчика уровня ядра, значит уже вляпались по самые уши.
Основная задача разработчика - это туда не попасть.

Сообщение отредактировано: ЫукпШ - 20.02.17, 09:22

Цитата Олег М @ 20.02.17, 08:42

Попробуй поотлаживать программу, где у тебя больше одного потока. Например найти дедлок.

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

Хотя причем тут многопоточные приложения, когда ты написал про сложные программы. Многопоточная - еще не значит сложная.

Добавлено 20.02.17, 09:24

Цитата Painkiller @ 20.02.17, 08:57

Как правильно подметили при отладке многопоточных приложений gdb пмомжет чуть менее чем никак ИМХО.

Да вы просто не умеете его готовить. В том же gdb можно вывести стек нужного потока, и хотя бы проследить цепочку вызовов. Отлаживать в консоль - пользуюсь таким оочень редко, иногда и консоли вообще нет, пользуюсь трасировкой в файл, но это только в тех случаях, когда отладка попросту бессмыслена(например баг с фокусами в GUI), там просто бесполезно что либо отлаживать.

Добавлено 20.02.17, 09:39

Цитата ЫукпШ @ 20.02.17, 09:13

Как посмотреть удалённо, что происходит с программой ?

Remote Debugger тебе в помощь, причем ЕМНИП, такая штука есть довольно давно и в любом более менее отладчике поддерживается. Последний год именно удаленным отладчиком и отлаживаю клиентов на виртуальной машине.

Добавлено 20.02.17, 09:40
Вы еще приведите в пример - а как релизную сборку отлаживать отладчиком

Сообщение отредактировано: KILLER - 20.02.17, 09:40

Цитата KILLER @ 20.02.17, 09:22

Вы еще приведите в пример - а как релизную сборку отлаживать отладчиком

Там им хорошо исключения ловить. Если они вообще будут повторяться под отладчиком.

Цитата Олег М @ 20.02.17, 10:26

Там им хорошо исключения ловить. Если они вообще будут повторяться под отладчиком.

Да отлаживаться тоже как то не плохо.

На самом деле, за последние годы средства отладки многопоточных приложений продвинулись очень сильно. Рассказывать сейчас лень и некогда, кому интересно -- гугл в помощь.

Сообщение отредактировано: shm - 20.02.17, 10:40

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

The program has unexpectedly finished.

теперь я хз как ее локализовать
мои стандартные методы не помогают, как я понял исключение возникает внутри Qt. Если посмотрите проект то на строчке:

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
    , mCpuWidget(this)
{
    qDebug() << "ctor MainWindow";
    ui->setupUi(this);
    SysInfo::instance().init();
    qDebug() << "mCpuWidget: " << &mCpuWidget;
    ui->centralWidget->layout()->addWidget(&mCpuWidget); //<-- видимо тут что то не так
}

Прикреплённый файлSysinfo.zip (7,69 Кбайт, скачиваний: 90)

пс. Проект на Qt Creator 4.2 + Qt 5.7 + MinGW 5.3 + Win10.

Сообщение отредактировано: Cfon - 20.02.17, 12:00

Цитата Cfon @ 20.02.17, 11:51

ui->centralWidget->layout()->addWidget(&mCpuWidget); //<-- видимо тут что то не так

А у тебя там nullptr что-нибудь не возвращает, в этой цепочке?

Цитата Олег М @ 20.02.17, 12:10

А у тебя там nullptr что-нибудь не возвращает, в этой цепочке?

нет ui инициализирован, mCpuWidget тоже создается.
centralWidget->layout()->addWidget() это хозяйтво уже Qt, что там происходит я не знаю

Сообщение отредактировано: Cfon - 20.02.17, 13:00

Попроуй сделать mCpuWidget указателем.
Вообще, создавать QObject на стеке, передавая ему указатель на родителя - верный способ нарваться на весёлые грабли

Цитата OpenGL @ 20.02.17, 13:10

Попроуй сделать mCpuWidget указателем.
Вообще, создавать QObject на стеке, передавая ему указатель на родителя - верный способ нарваться на весёлые грабли

спс позже проверю , пока решил по другому:

MainWindow::MainWindow(QWidget  *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
    , mCpuWidget(this)
{
    qDebug() << "ctor MainWindow";
    ui->setupUi(this);
    SysInfo::instance().init();
    qDebug() << "mCpuWidget: " << &mCpuWidget;
    //ui->centralWidget->layout()->addWidget(&mCpuWidget);
    setCentralWidget(&mCpuWidget); //<-- вот так все пучком
    qDebug() << ui->centralWidget->layout();
}

я не силен пока в Qt что там не так с layout() вроде как возвращает null.

Сообщение отредактировано: Cfon - 20.02.17, 13:17

Может быть там перед вызовом layout Нужно вызвать addlayout ? Хотя я в qt тоже не силен, так чисто, предположение.

Цитата KILLER @ 20.02.17, 13:30

Может быть там перед вызовом layout Нужно вызвать addlayout ? Хотя я в qt тоже не силен, так чисто, предположение.

да все верно в centralWidget не был задан layout исправил теперь все пучком
также исправил создание CpuWidget указатель :

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
    , mCpuWidget(new CpuWidget(this))
{
    qDebug() << "ctor MainWindow";
    ui->setupUi(this);
    SysInfo::instance().init();
    QLayout* layout = ui->centralWidget->layout();
    Q_ASSERT(layout);
    layout->addWidget(mCpuWidget);
}

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

баг обнаружил без отладчика своими проверенными методами ассерт + трассировка

Сообщение отредактировано: Cfon - 20.02.17, 16:14

Цитата KILLER @ 20.02.17, 09:22

Добавлено 20.02.17, 09:40
Вы еще приведите в пример - а как релизную сборку отлаживать отладчиком

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

Сообщение отредактировано: ЫукпШ - 20.02.17, 20:40

Так в релизе выставляешь - генерировать дебаг инфу, и профит.

Добавлено 20.02.17, 20:39
Можно еще оптимизацию и скорость отключить.

Цитата KILLER @ 20.02.17, 20:39

Так в релизе выставляешь - генерировать дебаг инфу, и профит.

Добавлено 20.02.17, 20:39
Можно еще оптимизацию и скорость отключить.

А в проге баг, который проявляется при изменении размеров приложения
и при изменении расположения различных его частей в памяти...
---
Любое измерение тем ближе к истине, чем меньше искажений вносит оно в объект.
При таком рассмотрении вопроса предложение остановить программу (в точке останова)
и поизучать её кишки выглядит просто глупо.

Сообщение отредактировано: ЫукпШ - 20.02.17, 20:46

Цитата ЫукпШ @ 20.02.17, 20:34

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

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

Добавлено 20.02.17, 20:45

Цитата ЫукпШ @ 20.02.17, 20:42

А в проге баг, который проявляется при изменении размеров приложения
и при изменении расположения различных его частей в памяти...

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

Добавлено 20.02.17, 20:47

Цитата ЫукпШ @ 20.02.17, 20:42

Любое измерение тем ближе к истине, чем меньше искажений вносит оно в объект.
При таком рассмотрении вопроса предложение остановить программу (в точке останова)
и поизучать её кишки выглядит просто глупо.

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

Сообщение отредактировано: KILLER - 20.02.17, 20:47

Цитата KILLER @ 20.02.17, 20:44

Добавлено 20.02.17, 20:45

Цитата ЫукпШ @ 20.02.17, 20:42

А в проге баг, который проявляется при изменении размеров приложения
и при изменении расположения различных его частей в памяти...

Берешь ставишь брекпоинт с условием, в котором пишешь "при изменении размеров" и попадаешь на него только тогда, когда у тебя размеры окна изменятся.

Понеслась...
Да не размеры окна.
Размеры самого приложения. Физический размер exe-файла.
---
Бесполезный разговор.

Цитата ЫукпШ @ 20.02.17, 20:49

онеслась...
Да не размеры окна.
Размеры самого приложения. Физический размер exe-файла.
---
Бесполезный разговор.

Значит ты привел самый бредовый пример, который только смог выдумать. Который написан через жопу, и в котором тебе не только дебаг, но еще и трейсы толком не помогут. Я даже не могу себе представить случай, когда нужно увеличивать размер exe во время его выполнения. Вирус чтоль какой то? Ну бредовый ведь пример, мой с фокусом и то реалистичней. А это, вымысел какой то. И причем тут дебагер? Раз я не могу отладить случай, когда появился баг, мать его во время увеличения размера программы, значит дебагер бесполезен? Или что ты хотел донести? Тут как бы при прочих равных - я под отладчиком найду багу за 2 часа, ты с трейсами потратишь 2 дня. Вот и все разница. Это плюс ко всему, что обычно и начинают курить с логов. А если логи ничего путного не сказали, то тогда начинается углубленный анализ проблемы с использованием отладчика.
Никогда твои трейсы тебе не помогут, если у тебя какой нибудь access violation необработанный, и программа с пришибленной логикой, и не просто на 10 классов поделка, а серьезная, с кучей сценариев поведения. То что ты будешь делать трейсами - увижу за 10 минут под отладчиком, найду место где падает и буду решать проблему. В то время как ты будешь пихать свои трейсы куда не попадя, с целью хотя бы локализировать место. Вот и вся разница между трейсами и отладкой.

Добавлено 21.02.17, 05:33

Цитата ЫукпШ @ 20.02.17, 20:34

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

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

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

Сообщение отредактировано: KILLER - 21.02.17, 05:33

Цитата Cfon @ 20.02.17, 16:03

баг обнаружил без отладчика своими проверенными методами ассерт + трассировка

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

В борьбе с багами все средства хороши.

Логи обычно помогают поймать и понять ошибке в логике и бизнес-логике. Особенно когда поведение внешнего интерфейса отличается от ожидаемого. А также внутренние ошибки логики. Отладчик напротив помогает бороться с аварийными ситуациями(access violation) и исключениями.
А вот проверка данных по входу делает программу устойчивой к ошибкам. Попутно это первый шаг к логам.
Статический анализ позволяет исключить описки и устранить забывчивость программиста. Так же тут помогают генераторы кода.
А вот тестирование. Воздействие и получение результата, влияет разом на все виды ошибок. Но основная суть её в фазинге. Зайти в те ветки условий в которые программа редко попадает. А метод чёрного ящика нацелен на поиск тех веток которых ещё и нет в программе, но они должны быть.


Логи очень хорошо помогают. Но умение ими правильно пользоваться сравни искусству. Уж больно мудрёная у них форма существования. Так как не понятно по каким событиям запускать логирование, а по каким молчать.

Сообщение отредактировано: Pavia - 21.02.17, 06:43

Цитата Pavia @ 21.02.17, 06:41

Логи очень хорошо помогают. Но умение ими правильно пользоваться сравни искусству. Уж больно мудрёная у них форма существования. Так как не понятно по каким событиям запускать логирование, а по каким молчать.

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

Цитата Олег М @ 21.02.17, 06:21

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

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

Цитата Painkiller @ 20.02.17, 08:57

Как правильно подметили при отладке многопоточных приложений gdb пмомжет чуть менее чем никак ИМХО.

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

Добавлено 21.02.17, 08:19

Цитата KILLER @ 21.02.17, 05:19

Значит ты привел самый бредовый пример, который только смог выдумать. Который написан через жопу, и в котором тебе не только дебаг, но еще и трейсы толком не помогут. Я даже не могу себе представить случай, когда нужно увеличивать размер exe во время его выполнения. Вирус чтоль какой то?

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

for(int i = 0; i < 100000; ++i)
    ;

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

Цитата Dushevny @ 21.02.17, 07:55

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

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

Цитата Dushevny @ 21.02.17, 07:55

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

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

Сообщение отредактировано: KILLER - 21.02.17, 08:30

Цитата KILLER @ 21.02.17, 08:29

Причем тут оптимизация по размеру?

Чьи слова?

Цитата KILLER @ 20.02.17, 20:39

Можно еще оптимизацию и скорость отключить.

Цитата KILLER @ 21.02.17, 08:29

А если я еще подключу какую нибудь библиотеку сторонюю - у меня еще больше размер файла станет, это что - вот это имелось ввиду?

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

Цитата KILLER @ 21.02.17, 08:29

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

Какой-то поток сознания пошел.

Цитата KILLER @ 21.02.17, 08:29

но тогда тебе не будут доступны значения переменных

Не тыкайте мне.

Цитата KILLER @ 21.02.17, 08:29

Не вижу проблем собирать две сборки и работать с той, которая тебе в данный момент нужнее.

Не видите - собирайте.

Сообщение отредактировано: Dushevny - 21.02.17, 09:43

Цитата Dushevny @ 21.02.17, 09:40

Чьи слова?

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

Цитата Dushevny @ 21.02.17, 09:40

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

А если используется, то дебагером мы уже не воспользуемся? Размер же программы изменился

Цитата Dushevny @ 21.02.17, 09:40

Какой-то поток сознания пошел.

Да нет, это похоже что ты не понимаешь к чему вообще относилось то, что ты решил процитировать.

Цитата Dushevny @ 21.02.17, 09:40

Не тыкайте мне.

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

Цитата Dushevny @ 21.02.17, 09:40

Не видите - собирайте.

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

Цитата KILLER @ 21.02.17, 10:26

У тебя в релизе и дебаге получаются две разные программы? Это твои личные проблемы.

У вас они получаются побитно идентичные? Нет? Значит это разные программы. Даже если они (иногда) делают примерно одно и то же.

Цитата KILLER @ 21.02.17, 10:26

Так зачем ты тогда в чужой спор лезешь, не зная о чем идет речь?

Это форум. Здесь каждый может принять участие. Но продолжать общаться с таким хамоватым собеседником желания нет. Пожалуйте в игнор.

Цитата KILLER @ 21.02.17, 10:26

У меня нет с этим проблем.

Ваши проблемы тут мало кого интересуют.

Сообщение отредактировано: Dushevny - 21.02.17, 11:09

Цитата Dushevny @ 21.02.17, 11:07

У вас они получаются побитно идентичные? Нет? Значит это разные программы. Даже если они (иногда) делают примерно одно и то же.

Причем тут побитно идентичные? К чему это вообще? С логической точки зрения, они идентичные. Ты написал программу, которая что то делает, она это будет делать и в релизе и в дебаге. А во что это транслирует компилятор - это вообще не твое дело.
И как это относится(в частности включение/отключение оптимизации) к этому высказыванию?

Цитата ЫукпШ @ 20.02.17, 20:42

А в проге баг, который проявляется при изменении размеров приложения
и при изменении расположения различных его частей в памяти...

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

Цитата Dushevny @ 21.02.17, 11:07

Это форум. Здесь каждый может принять участие. Но продолжать общаться с таким хамоватым собеседником желания нет. Пожалуйте в игнор.

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

Цитата Dushevny @ 21.02.17, 11:07

Ваши проблемы тут мало кого интересуют.

Твои проблемы и подавно.

Сообщение отредактировано: KILLER - 21.02.17, 11:33

Цитата KILLER @ 21.02.17, 11:26

Что за прога такая - что меняет свой размер? Каким образом меняется размер приложения?

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

пробовал отловить тот же баг через F5 (режим отладки), но он так долго запускается (тяжелая штука отладчик), думаю ноут слабый..
(напомню это Qt Creator 4.2, на Visual Studio 2010 все намного быстрее )
в итоге да он остановился на той строке с исключением, но честно говоря я сразу не понял что в ней не так

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

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

Сообщение отредактировано: Cfon - 21.02.17, 12:25

Цитата Cfon @ 21.02.17, 12:09

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

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

Цитата Cfon @ 21.02.17, 12:09

в итоге да он остановился на той строке с исключением, но честно говоря я сразу не понял что в ней не так

А по трассировке понял?

Цитата Олег М @ 21.02.17, 12:22

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

а это имелось ввиду тогда все ясно

Цитата Олег М @ 21.02.17, 12:22

А по трассировке понял?

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

Сообщение отредактировано: Cfon - 21.02.17, 12:34

Цитата Олег М @ 21.02.17, 12:22

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

А причем тут релиз и дебаг? В посте ЫукпШ'а об этом ничего не сказано и близко.

Цитата Cfon @ 21.02.17, 12:30

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

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

Цитата Олег М @ 21.02.17, 12:22

Соответственно ошибки могут не повторяться, либо там, либо там, кроме самых грубых.

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

Цитата KILLER @ 21.02.17, 13:09

Не знаю как там в книжках пишут. На практике в 95% если не в 99% случаев ошибка в релизе, воспроизводится и в дебаг конфигурации.

На практике 95% ошибок, можно и без отладчика найти, просто посмотрев код. А вот потоки, стек, память ведут себя в релизе и дебаге по-разному.

Цитата Олег М @ 21.02.17, 13:13

На практике 95% ошибок, можно и без отладчика найти, просто посмотрев код. А вот потоки, стек, память ведут себя в релизе и дебаге по-разному.

Смотря какая программа и кто ее писал. У меня таких практик не было на работе.

Добавлено 21.02.17, 13:17

Цитата Олег М @ 21.02.17, 13:13

А вот потоки, стек, память ведут себя в релизе и дебаге по-разному.

По разному - это как?

Т.е. ты объявил динамический массив на 100 элементов - ожидаешь, что у тебя выделится память по 100 элементов, в дебаге и релизе будет по разному выделено или что?

Цитата KILLER @ 21.02.17, 13:16

По разному - это как?

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

Цитата KILLER @ 21.02.17, 13:16

Смотря какая программа и кто ее писал.

Не, в любых.

Цитата KILLER @ 21.02.17, 11:26

Что за прога такая - что меняет свой размер? Каким образом меняется размер приложения? Часто ты в релизе отключаешь оптимизацию и толкаешь пользователям?

Речь как раз и шла о том, что в отладочной и в релизной версии из-за разных настроек компилятора/оптимизатора генерится разный код со всеми вытекающими, в том числе и разным размером исполняемого кода. Это вы не поняли, о чем шла речь и бросились бороться с плодом своих фантазий. К последнему вопросу: я оптимизацию не отключаю вообще. Если вы не в состоянии отлаживать оптимизированный код и вам для отладки приходится отключать оптимизацию - сочувствую.

Цитата Олег М @ 21.02.17, 13:21

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

А может проявляться в дебаге, но не проявляться в релизе. И что?

Цитата Олег М @ 21.02.17, 13:21

В потоках - любое изменение может повлиять на очерёдность исполнения потоков, очерёдность блокировок и т.д.

Любое изменение чего? Когда косячишь с потоками, оно что в релизе, что в дебаге полбу стучит.

Цитата Олег М @ 21.02.17, 13:21

Не, в любых.

Не в любых. В школьных и универовских микрозадачах - в большинстве случаев так и есть. А в реальности, 95% багов без отладчика, логов и трасировки нихрена ты даже не поймешь где стрельнуло. Ну вот тебе в 16 посте запостили код - чего ты не сказл "У тебя layout" нулевой, это ведь было очевидно даже по комментариям в коде. Можешь пройтись по темам, выбрать с 10 тем, и посмотреть сколько ты без отладчика сходу скажешь в чем ошибка и где. Это при том, что тут задачки в основном синтетические и упрощены до предела. так что в корне не согласен с эти высказыванием. В противном случае багтрекеры были бы не в моде нынче.

Добавлено 21.02.17, 13:31

Цитата Dushevny @ 21.02.17, 13:23

Речь как раз и шла о том, что в отладочной и в релизной версии из-за разных настроек компилятора/оптимизатора генерится разный код со всеми вытекающими

Речь вообще шла о том, что отладчик нахрен не нужен, трейсы наше все. И были попытки привести когда он бесполезен. Я ЫукпШ'у сказал "ты еще приведи в качестве аргумента, что программу скомпиленную в релизе нельзя отладить", что он и привел. Я ему ответил - что для того чтоб отлаживать в релизе - нужно включить отладочную инфу, и еще можно отключить оптимизацию, если ты хочешь смотреть значения переменных. На что он начал приводить какие то баги при изменении размеров программы. Причем тут изменение размера программы вообще?

Добавлено 21.02.17, 13:32

Цитата Dushevny @ 21.02.17, 13:23

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

У меня вообще проблем с отладчиком нет. Это тут у некоторых многопоточность не отлаживается, и остальная муть.

Цитата KILLER @ 21.02.17, 13:26

А может проявляться в дебаге, но не проявляться в релизе. И что?

То что и релиз ведут себя по-разному.

Цитата KILLER @ 21.02.17, 13:26

Любое изменение чего? Когда косячишь с потоками, оно что в релизе, что в дебаге полбу стучит.

В случае грубых ошибок - да. Но в этом случае и отладчик не нужен.

Цитата KILLER @ 21.02.17, 13:26

Ну вот тебе в 16 посте запостили код - чего ты не сказл "У тебя layout" нулевой

Потому что я не знаю, что такое layout. Поэтому посоветовал проверить всю цепочку и больше так не писать.

Сообщение отредактировано: Олег М - 21.02.17, 13:33

Цитата Олег М @ 21.02.17, 13:33

То что и релиз ведут себя по-разному.

Могут, и что? А еще разрядность системы имеет значение и остальная муть. И что дальше?

Цитата Олег М @ 21.02.17, 13:33

В случае грубых ошибок - да. Но в этом случае и отладчик не нужен.

Ок, а не грубые ошибки это какие? Сферические в вакууме, какие нибудь?

Цитата Олег М @ 21.02.17, 13:33

Потому что я не знаю, что такое layout. Поэтому посоветовал проверить всю цепочку и больше так не писать.

Там по синтаксису понятно что layout это как минимум указатель. И как же ты не нашел ошибку такую простую? Ведь в 95% случаев без отладчика на глаз можно обнаружить.

Сообщение отредактировано: KILLER - 21.02.17, 13:36

Цитата KILLER @ 21.02.17, 13:36

Там по синтаксису понятно что layout это как минимум указатель. И как же ты не нашел ошибку такую простую? Ведь в 95% случаев без отладчика на глаз можно обнаружить.

Единственно, что там понятно по синтаксису, что они там все указатели. Если бы они не были выстроены в одну цепочку, то и проблемы бы не возникло

Добавлено 21.02.17, 13:44

Цитата KILLER @ 21.02.17, 13:36

Ок, а не грубые ошибки это какие? Сферические в вакууме, какие нибудь?

С lock-free алгоритмами ни разу не работал? Да и обычные дедлоки зачастую отловить не так-то просто

Сообщение отредактировано: Олег М - 21.02.17, 13:45

Цитата Олег М @ 21.02.17, 13:43

Единственно, что там понятно по синтаксису, что они там все указатели. Если бы они не были выстроены в одну цепочку, то и проблемы бы не возникло

Так погоди, ты же сам сказал что телепат 95 лвла. Теперь уже ты не можешь без отладчика сказать где ошибка. А что же случилось? В чем разница? Это какая то хитрая ошибка? На сколько помню еще в универе учат проверять указатели на Null перед использованием. Т.е. это целиком и полностью подпадает под 95% ошибок, которые на глаз ловятся. Как же ты не заметил то?

Добавлено 21.02.17, 13:46

Цитата Олег М @ 21.02.17, 13:43

С lock-free алгоритмами не разу не работал? Да и обычные дедлоки зачастую отловить не так-то просто

Работал, как то у меня что в дебаге, что в релизе поведение было одинаковое.

Цитата Олег М @ 21.02.17, 13:43

Да и обычные дедлоки зачастую отловить не так-то просто

Где? В релизе или дебаге? Вот была у меня взаимоблокировка да еще с двумя сетевыми компонентами, в релизе ловил, отладчиком. Отловил. Без отладчика, трейсами - до второго пришествия бы ловил.

Цитата KILLER @ 21.02.17, 13:44

Так погоди, ты же сам сказал что телепат 95 лвла. Теперь уже ты не можешь без отладчика сказать где ошибка. А что же случилось? В чем разница? Это какая то хитрая ошибка? На сколько помню еще в универе учат проверять указатели на Null перед использованием. Т.е. это целиком и полностью подпадает под 95% ошибок, которые на глаз ловятся. Как же ты не заметил то?

Я ж вроде и сказал, где искать ошибку. Нет?

Добавлено 21.02.17, 13:50

Цитата KILLER @ 21.02.17, 13:44

Где? В релизе или дебаге? Вот была у меня взаимоблокировка да еще с двумя сетевыми компонентами, в релизе ловил, отладчиком. Отловил. Без отладчика, трейсами - до второго пришествия бы ловил.

Там у меня пост есть, по поводу thread-safe shared_ptr. Найди в нём ошибку, хоть с отладчиком, хоть без

Цитата Олег М @ 21.02.17, 13:47

Я ж вроде и сказал, где искать ошибку. Нет?

Так погоди, ты во первых писал:

Цитата

На практике 95% ошибок, можно и без отладчика найти, просто посмотрев код.

Тебе дали код, почему ты не нашел ошибку без отладчика, просто посмотрев код? Причем там кода - с гулькин нос, чуть больше, чем в хело ворлде. А представь у тебя не синтаксическая ошибка, а логическая и программа не из 10 строчек, а из 100 000 строчек, и спенарий такой запареный, что в страшном сне не приснится(а так оно и бывает в 95% случаев) - как ты собрался искать без отладчика ошибку, если ты в 10 строчках ее не нашел?

Добавлено 21.02.17, 13:52

Цитата Олег М @ 21.02.17, 13:47

Там у меня пост есть, по поводу thread-safe shared_ptr. Найди в нём ошибку, хоть с отладчиком, хоть без

А оно мне нужно?

Цитата KILLER @ 21.02.17, 13:51

Тебе дали код, почему ты не нашел ошибку без отладчика, просто посмотрев код?

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

Добавлено 21.02.17, 13:56

Цитата KILLER @ 21.02.17, 13:51

А оно мне нужно?

Не знаю, смотри сам. Думаю, было бы полезно. А то одни пустые слова по тысячи запаренных строк.

Цитата Олег М @ 21.02.17, 13:53

Ну, очевидно, потому что я не знаю предметную область.

так там практически какой то абстрактный код, три строчки несут какой то смысл. Какая предметная область? Видно же что добавляют виджет на лэйаут главного виджета.

Цитата Олег М @ 21.02.17, 13:53

Тем не менее я указал, что нужно сделать, чтоб найти ошибку.

Можно было с таким же успехом сказать посмотри в отладчике. И? Вообще то у него даже в коде написано:

Цитата

ui->centralWidget->layout()->addWidget(&mCpuWidget); //<-- видимо тут что то не так

тут как бы в одной строчки кода, сложно посоветовать что то другое. Но ты ведь не нашел ошибку. А хотя написал что в 95% случаев и без отладчика находишь. Мне бы твой скилл...

Добавлено 21.02.17, 13:59

Цитата Олег М @ 21.02.17, 13:53

Не знаю, смотри сам. Думаю, было бы полезно. А то одни пустые слова по тысячи запаренных строк.

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

Цитата KILLER @ 21.02.17, 13:58

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

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

Цитата Олег М @ 21.02.17, 14:04

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

Фи, думай что хочешь. У меня свое мнение на этот счет.

Цитата Cfon @ 20.02.17, 13:15

я не силен пока в Qt что там не так с layout() вроде как возвращает null.

Цитата Cfon @ 20.02.17, 13:15

Может быть там перед вызовом layout Нужно вызвать addlayout ? Хотя я в qt тоже не силен, так чисто, предположение.

У каждого виджета есть ссылка на свой лайаут:

Цитата

QLayout *QWidget::layout() const
Returns the layout manager that is installed on this widget, or 0 if no layout manager is installed.
The layout manager sets the geometry of the widget's children that have been added to the layout.

Задается лайаут методом void QWidget::setLayout(QLayout *layout)

Таким образом, до помещения виджета в качестве центрального, с помощью void QMainWindow::setCentralWidget(QWidget *widget) - этот виджет должен быть построен заранее. Естественно, если он содержит дочерние элементы (виджеты), они так же должны быть построены заранее и помещены в лайаут(ы). Ну и конечно же важна последовательность построения.

Небольшой примерчик

MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent)  {
  QWidget *W = new QWidget();
  QLabel *Label = new QLabel("Enter string:");
  QLineEdit *Edit = new QLineEdit();
  QPushButton *Ok = new QPushButton("Ok");
  QPushButton *Cancel = new QPushButton("Cancel");
  QHBoxLayout *H1 = new QHBoxLayout();
  QHBoxLayout *H2 = new QHBoxLayout();
  QVBoxLayout *V = new QVBoxLayout();
  H1->addWidget(Label);
  H1->addWidget(Edit);
  H2->addStretch();
  H2->addWidget(Ok);
  H2->addWidget(Cancel);
  V->addLayout(H1);
  V->addLayout(H2);
  W->setLayout(V);
  setCentralWidget(W);
  resize(320,96);
}

В результате получится окошко (ничего не делающее, просто отрисовка):



Ну и еще замечание ... Почему я нигде не задаю "родителя" при создании элемента? Дело в том, что методы типа addWidget, addLayout, setCentralWidget ... сами это прописывают. В результате последующего разрушения родительского виджета - все дочерние виджеты и размещения автоматом предварительно разрушаются.

Добавлено 21.02.17, 22:33
ЗЫ: В примере можно было не городить вложенные размещения, а выбрать какой-нить другой "размещатель", например, QGridLayout. Но я специально сделал так, чтобы была более наглядна последовательность построения.

Цитата JoeUser @ 21.02.17, 22:29

У каждого виджета есть ссылка на свой лайаут:

Цитата

QLayout *QWidget::layout() const
Returns the layout manager that is installed on this widget, or 0 if no layout manager is installed.
The layout manager sets the geometry of the widget's children that have been added to the layout.

Задается лайаут методом void QWidget::setLayout(QLayout *layout)

Таким образом, до помещения виджета в качестве центрального, с помощью void QMainWindow::setCentralWidget(QWidget *widget) - этот виджет должен быть построен заранее. Естественно, если он содержит дочерние элементы (виджеты), они так же должны быть построены заранее и помещены в лайаут(ы). Ну и конечно же важна последовательность построения.

спс ясно