Здравствуйте, b0r3d0m, Вы писали:
B>Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
Многие замечают такое. Называется опыт и долгое время работы в одной области. Стоит радикально сметь область деятельности, как отладчик тут же понадобится, сам собой.
Кстати говоря, очень много 'учителей программированию' после таких наблюдений всерьез задвигают идею о том, что отладчик не нужен вовсе, типа
'я написал гигантскую софтину ХХХ без отладчика, потому и вам отладчик не нужен'
'я умею (пользоваться логами, тестами, компилятором, проектировать), поэтому и вам отладчик не нужен'
Здравствуйте, мыщъх, Вы писали:
B>> На Debug-сборке могут проявиться какие-то баги, которые бы, возможно, не всплыли в случае Release. М>debug сборка она не только для прогона под отладчиком. в дебаг сборке она сама может себя отлаживать. в частности ловить обращение к освобожденной памяти или выходы за пределы блока. там же практически у всех компиляторов совершенно разный рантайм.
Здравствуйте, IID, Вы писали:
М>>debug сборка она не только для прогона под отладчиком. в дебаг сборке она сама может себя отлаживать. в частности ловить обращение к освобожденной памяти или выходы за пределы блока. там же практически у всех компиляторов совершенно разный рантайм. IID>+1
Только если уж быть совсем честными по отношению к самим себе, то в нынешних плюсах подобные детские ошибки нужно создавать практически специально.
Это если уж забыть о выделенном. Из чего следует, что в дебаге могут никак не проявляются баги, которые потом портят много крови в релизной сборке.
Вот, кстати, наткнулся однажды на интересное видео о возможностях gdb: https://www.youtube.com/watch?v=PorfLSr3DDI
всего 15 минут, показывает как найти stack corruption используя reverse debugging
Здравствуйте, chaotic-kotik, Вы писали:
CK>Когда я работал над реализацией B-tree в колоночной OLAP системе — использовал отладчик постоянно.
Отлично покрывается юнит-тестами.
CK>Помимо анализа состояния отладчик можно использовать и для того, чтобы смоделировать какие-нибудь ситуации.
С помощю автотестов можно смоделировать любые ситуации, которые можно смоделировать отладчиком. И огромное количество ситуаций, которые отладчиком смоделировать либо невозможно, либо очень сложно/очень долго/очень запарно.
CK>Ну например интересно тебе, что будет если потоки изменят состояние переменных в определенном порядке — ставишь точки останова, фризишь потоки по очереди, сначала исполняешь один поток, фризишь, потом другой — можно race condition так смоделировать очень легко.
При всем уважении, но это называется "закат солнца вручную".
CK>Еще отладчик, это единственный способ разобраться в проблеме после того как приложение упало.
Если нужно именно разобраться и починить, то как раз не единственный.
Правда, колстек все равно нужен.
Здравствуйте, Privalov, Вы писали:
P>Кроме Борланд, Паскаль продавали и другие конторы. Та же Микрософт. Но среда у Борланд была намного лучше,
QuickPascal от MS, вышедший во времена TP 5 был намного лучше продукта от Borland. В нем была многооконная ИДЕ с поддержкой цветной подсветки кода (у Борланд это появилось в 6.0), была поддержка ООП (раньше, чем вышел TP 5.5). Можно было программировать в режиме VGA 320*200*256 цветов. Почему он не пошел в массы — неизвестно.
Здравствуйте, aloch, Вы писали:
A>QuickPascal от MS, вышедший во времена TP 5 был намного лучше продукта от Borland. В нем была многооконная ИДЕ с поддержкой цветной подсветки кода (у Борланд это появилось в 6.0), была поддержка ООП (раньше, чем вышел TP 5.5). Можно было программировать в режиме VGA 320*200*256 цветов. Почему он не пошел в массы — неизвестно.
Я не работал с Quick Pascal, но видел Quick C. Насколько я понимаю, MS выпустила его в качестве конкурента Turbo C. Скорость компиляции у него была охренительная. Но на этом все преимущества и заканчивались. Quick C стоил дешевле, но в 90-е в бСССР мало кто этим заморачивался.
MS C был существенно лучше Quick-а. MS C 5.0 еще отставал от Turbo C 2.0, а 6.0 уже выровнял ситуацию.
Правда, у Borland уже был нормальный C++ 2.0, а у MS что-то не получалось. Пока они выпустили свой MS C++ 7.0, у Borland появился C++ 3.0, который уже знал про шаблоны и, ЕМНИП, про исключения.
Документацию к системам от Borland очень быстро перевели на русский. Тоже поспособствовало распространению их продуктов.
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, Privalov, Вы писали:
P>>Кроме Борланд, Паскаль продавали и другие конторы. Та же Микрософт. Но среда у Борланд была намного лучше,
A>QuickPascal от MS, вышедший во времена TP 5 был намного лучше продукта от Borland. В нем была многооконная ИДЕ с поддержкой цветной подсветки кода (у Борланд это появилось в 6.0), была поддержка ООП (раньше, чем вышел TP 5.5). Можно было программировать в режиме VGA 320*200*256 цветов. Почему он не пошел в массы — неизвестно.
Скорее всего из-за сговора — Borland и Microsoft договорились не мешать друг другу.
В конце 1980-х Borland уже играла на поле Microsoft со своим Turbo Basic, конкурируя с QBasic/QuickBASIC.
давйте угадаю, речь о проектах до 10 файлов которые писали только вы?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, b0r3d0m, Вы писали:
B>>А вы что думаете?
L>Я тут давно в роли городского сумасшедшего выступаю на этой ниве. При разработке отладчик и правда не нужен. Использование его — контрпродуктивно.
при разработке проекта с нуля без кривых зависимостей или с зависммостями, покрытыми тестами и с хорошей документацией.
FTFY.
а в реальной жызне разработка предполагает ковыряние в кишках кода, который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда.
Здравствуйте, nigh, Вы писали:
N>а в реальной жызне разработка предполагает ковыряние в кишках кода, который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, nigh, Вы писали:
N>>а в реальной жызне разработка предполагает ковыряние в кишках кода, который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда.
L>Ой, не наступай на больной мозол
ну вот вы все понимаете и разделяете чужую боль. Зачем же выступать клоуном в этом паноптикуме и агитировать а юнит-тесты против дебаггинга?
Здравствуйте, nigh, Вы писали:
L>>Ой, не наступай на больной мозол N>ну вот вы все понимаете и разделяете чужую боль. Зачем же выступать клоуном в этом паноптикуме и агитировать а юнит-тесты против дебаггинга?
Потому что есть слабая надежда, что кто-то подумает и сделает правильно. И может быть, ковыряться в коде, "который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда", нужо будеть немного реже.
.jpg)
