я не прав? понимаешь в чём беда. я программировал в твоём стиле (да - и на msvs! и на трубопаскале! и в дельфях! и через точечку! и мышкой! и отлаживал!) и программирую эффективно. я могу сравнить. ты сравнить не можешь но подсознательно (ведь ты даааалеко не глупый человек) понимаешь что делаешь работу неэффективно.
Ты можешь знать из моих пстов, что я пользуюсь отладчиком и средой Visual Studio, но не можешь знать, как именно, как часто и с каким эффектом. Таким образом, у тебя почти ноль достоверной информации о том, как программирую я - и тебе приходится дорисовывать образ. А рисуешь ты картинку с себя, молодого, глупого, использующего дебаггер или что там еще.
Это называется "проекция": ты проецируешь себя-молодого-глупого на меня, и сравниваешь не меня с собой, а себя-молодого-глупого с собой теперешним :)
вот как раз да - знаю что пользуешься вс. видя результаты труда понимаю что опыта валом и используешь вс довольно эффективно (дебаггер для написания звукового софта? хммм... ну не знаю как его там использовать совсем ;]). знаю что можешь увеличить эффективность если перейдёшь на правильные тулзы.
"Блядь, жопа!" Не напоминайте мне про дебаггер и звуковой софт. Хуже этого наверно только отлаживать драйвера видеокарт и как хорошо что я оттуда съебал.
Вообще то логами. Но блядь с этой многопоточностью и событиями тут даже логи с трудом помогают - нужные какие-то строго типизированные логи и интеллектуальный визуализатор для них.
Звуковой софт в этом смысле не сильно отличается от любого real-time софта. А там далеко не всегда тебе нужно код исполняемый в норме real-time, в процессе отладки тоже исполнять real-time. Скажем, вчера возился с багой: в одном канале звук образуется, а в другом - нули, причем, со второй половины фрагмента. Алгоритм состоял из двух этапов. В отладчике поставил breakpoint между ними, проиграл до этого места и в отладчике же посмотрел, появились ли нули после второго этапа. То же самое можно было сделать, вставив отладочную печать между этапами, но это дольше по времени.
Дольше в основном за счет факторов: 1) компиляция (код находился в часть включаемом хэдере в форме template, его изменение вызвало бы массовую перекомпиляцию дважды - до и после) 2) саму отладочную печать тоже, возможно, пришлось бы отлаживать - нет гарантии, что напишешь слету без ошибок 3) отладочную печать писать было дольше, чем разворачивать деревья объектов в окне отладчика - по той причине, что звуковые буфера с упомянутыми нулями инкапсулированы в объектах потоков, надо спускаться на несколько уровней, вспоминать, как называется каждое поле и вставлять фрагмент кода, который высчитывает, где находится середина звукового фрагмента
1. ну это проблемы убогости с++. я их для себя решил просто - больше не пишу на с++ ;)) 2. имея нормальную либу для этого - всё делается спинным моском и ошибки исключены. 3. это потому что проект изначально не заточен под отладку выводом, да - в этом случае будет дольше. надо было сразу нормально делать ;)
1. Чем-то мне это напоминает сталинское "нет человека - нет проблемы" :))
2. Нормальную либу для этого - чего? Помянутый код был частью моей либы, которая, я даже надеюсь, что нормальная... местами :)))
3. Есть в нем и отладка выводом, например, можно включать-выключать горячими клавишами логгирование сообщений в окнах, переключать лог в дебаг-окно или на файл, вот только в данном конкретном случае отладка средой оказалась быстрее - по перечисленным причинам. Я бы никогда не подумал, что может понадобиться быстро вычислить и посмотреть уровень чуть дальше, чем в середине блока, причем, в промежутке между двумя конкретными функциями.
1. именно. нет говнокода - нет проблемы. 2. нормальную либы для отладочного вывода. 3. имея набор фунок для дампа всего-что-только-можно (а оно пишется на полном автомате) вывод нужной для тебя инфы в данном случае бы занял минуту какую.
2. такая либа имеется, но этим инструмэнтом ковыряться дольше - в данном конкретном случае, конечно 3. какое совпадение: есть такой набор фунок, делает дамп всего-что-только-можно - называется "отладчик среды" :) а ты его сам пишешь? бедняга :)
Не имееешь ты его всегда, во всяком случае в языках без RTTI/reflection/макросов/метапрограмминга. Нужно сидеть и рисовать как пню те дампы для произвольных структур :)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
no subject
no subject
no subject
no subject
Это называется "проекция": ты проецируешь себя-молодого-глупого на меня, и сравниваешь не меня с собой, а себя-молодого-глупого с собой теперешним :)
no subject
вот как раз да - знаю что пользуешься вс. видя результаты труда понимаю что опыта валом и используешь вс довольно эффективно (дебаггер для написания звукового софта? хммм... ну не знаю как его там использовать совсем ;]). знаю что можешь увеличить эффективность если перейдёшь на правильные тулзы.
no subject
Не напоминайте мне про дебаггер и звуковой софт. Хуже этого наверно только отлаживать драйвера видеокарт и как хорошо что я оттуда съебал.
no subject
no subject
no subject
no subject
Дольше в основном за счет факторов:
1) компиляция (код находился в часть включаемом хэдере в форме template, его изменение вызвало бы массовую перекомпиляцию дважды - до и после)
2) саму отладочную печать тоже, возможно, пришлось бы отлаживать - нет гарантии, что напишешь слету без ошибок
3) отладочную печать писать было дольше, чем разворачивать деревья объектов в окне отладчика - по той причине, что звуковые буфера с упомянутыми нулями инкапсулированы в объектах потоков, надо спускаться на несколько уровней, вспоминать, как называется каждое поле и вставлять фрагмент кода, который высчитывает, где находится середина звукового фрагмента
no subject
2. имея нормальную либу для этого - всё делается спинным моском и ошибки исключены.
3. это потому что проект изначально не заточен под отладку выводом, да - в этом случае будет дольше. надо было сразу нормально делать ;)
no subject
2. Нормальную либу для этого - чего? Помянутый код был частью моей либы, которая, я даже надеюсь, что нормальная... местами :)))
3. Есть в нем и отладка выводом, например, можно включать-выключать горячими клавишами логгирование сообщений в окнах, переключать лог в дебаг-окно или на файл, вот только в данном конкретном случае отладка средой оказалась быстрее - по перечисленным причинам. Я бы никогда не подумал, что может понадобиться быстро вычислить и посмотреть уровень чуть дальше, чем в середине блока, причем, в промежутке между двумя конкретными функциями.
no subject
2. нормальную либы для отладочного вывода.
3. имея набор фунок для дампа всего-что-только-можно (а оно пишется на полном автомате) вывод нужной для тебя инфы в данном случае бы занял минуту какую.
no subject
3. какое совпадение: есть такой набор фунок, делает дамп всего-что-только-можно - называется "отладчик среды" :) а ты его сам пишешь? бедняга :)
no subject
no subject
no subject
Нужно сидеть и рисовать как пню те дампы для произвольных структур :)
no subject