Но printf всетаки не всегда, но помогает.
Но нахрена, если есть брейкпоинты и отладчик?
А если нет нормальной среды разработки? К примеру когда ознакамливался с Go нихуя не было дебагера.
Не писать ничего на языках, где нет нормальный среды разработки, очевидно же.
Я пишу на ассемблере под Sega Mega Drive. Чо еще посоветуешь?
А какой у тебя сейчас год?
год исполнения моей мечты: писать игры под старую добрую 16-битку.
с такими знаниями я на современную платформу пишу весьма оптимизированный код,
потому что знаю как все крутится под капотом.
не каждый обладает силой воли чтобы учить ассемблер знаешь ли
с такими знаниями я на современную платформу пишу весьма оптимизированный код,
потому что знаю как все крутится под капотом.
не каждый обладает силой воли чтобы учить ассемблер знаешь ли
Там больше половины эмуляторов со встроенными отладчиками и ЭМУЛИРУЕМЫМИ ошибками реальных кристаллов.
на железке запускал, виснет прямо на старте.
ЧТО ПОСОВЕТУЕШЬ?
ЧТО ПОСОВЕТУЕШЬ?
Написать нормальную среду разработки вместе с дебаггером. Лучше - аддон к VS.
Скажи это разработке сайта на js
Так гугл хром разве не имеет отличный отладчик?
В ГуглоХроме, кстати, наверное, лучший отладчик. Намного лучше, чем известные мне под C#.
А еще у многих браузеров есть API, которое позволяет делать так, что бы в IDE все транслировалось.
Я так TypeScript отлаживал в Visual Studio Code.
Я так TypeScript отлаживал в Visual Studio Code.
тогда уж bug._value
Видишь там в софте выскочил баг
после 10ка индусов
иди покодь там
а когда надоест сделай бекап
и с проекта ливай
после 10ка индусов
иди покодь там
а когда надоест сделай бекап
и с проекта ливай
этот баг в отладчике
Не всегда решает.
Например, если баг завязан на какие-нибудь циклограммы или другие реалтаймовости. А бывает что тайминги настолько жесткие, что даже лишний snprintf меняет поведение. Вопщем при отладке железа иногда приходится сильно заморочиться. Как вариант наименее инвазивной отладки в таких случаях - менять уровень на какой-нибудь не очень важной линии, по которой засинхронизирован осциллограф или логический анализатор, подключенный к шине.
Например, если баг завязан на какие-нибудь циклограммы или другие реалтаймовости. А бывает что тайминги настолько жесткие, что даже лишний snprintf меняет поведение. Вопщем при отладке железа иногда приходится сильно заморочиться. Как вариант наименее инвазивной отладки в таких случаях - менять уровень на какой-нибудь не очень важной линии, по которой засинхронизирован осциллограф или логический анализатор, подключенный к шине.
В этом случае пишете полу сырые данные в буфер и в свободное время отдаёте в сторону ПК через медленный UART.
Лично я делаю так. Либо UART + DMA без printf (ибо долго), а подбрасыванием байтов в этот самый DMA буфер.
Лично я делаю так. Либо UART + DMA без printf (ибо долго), а подбрасыванием байтов в этот самый DMA буфер.
Прочитайте внимательно - я написал snprintf, то есть да, в буфер для последующей ДМА-выдачи :)
А так-то да, в большинстве случаев такого решения достаточно.
А так-то да, в большинстве случаев такого решения достаточно.
Когда код работает на удаленной машине и нет вообще никакой возможности подключить отладчик. У меня недавно такой случай был.
Из инструментов только git и jenkins. И ебись как хочешь.
Из инструментов только git и jenkins. И ебись как хочешь.
Вместо printf должны быть нормальные логи - код должен быть проинструментирован избыточно. А втыкать принты (особенно в многопоточном или респределённом коде) это потенциально подкладывать себе ещё больше проблем (впрочем для многопоточки это же утверждение валидно и в случае использования деббагера)
Нужно было еще одеялкомtry-catch попробовать
И throw exception() обязательно
Оригинал гифки есть на ютубе ?
Ну автор https://www.youtube.com/christiandelgrosso , только у него на канале этого всего настолько дохуя, что хз как найти.
А так в фейсбуке есть в том же. https://www.facebook.com/watch/?v=599584830798661
А так в фейсбуке есть в том же. https://www.facebook.com/watch/?v=599584830798661
Спс
Чтобы написать коммент, необходимо залогиниться