Здравствуйте, netch80, Вы писали:
N>>>unique_ptr/shared_ptr не поможет? ЕМ>>Как оно может помочь само по себе?
N>Хранишь под таким указателем созданный объект ошибки. Набиваешь параметрами. Даже при проблемах с RVO максимум цены — это увеличение и уменьшение счётчика ссылок.
Тогда возникает вопрос, где и когда создавать такой объект. Если снаружи, то его нужно как-то передать внутрь — или в параметрах каждой функции, или в какой-нибудь глобальной структуре. Если внутри, то не получится, как минимум, сообщить наружу о том, для чего именно не хватило динамической памяти. Хотя в современных реалиях вероятность нехватки памяти для работы моего кода можно считать строго нулевой.
N>Уточнение: я про юзерленд. В ядре TLS нет совсем, и не будет.
Строго говоря, в ядре нет проблем сделать TLS для собственных потоков, создаваемых модулем ядра. Проблема только с клиентскими потоками, вызывающими модуль снаружи.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> то неплохо бы вернуть наверх более подробную информацию, которую можно показать пользователю, чтобы он имел более-менее адекватное представление о проблеме.
"Подробная информация, которую можно показать пользователю" в целом ограничена количеством заранее заготовленных строк, которые мы показываем в messagebox или еще где, даже если это строки вида "Не удалось открыть файл %s в папке %s потому, что %s" Показывать пользователю что то более сложное чаще всего (от софта и аудитории конечно зависит) не имеет смысла. Пользователю ведь зачем это сообщение — или чтобы разобраться самому или отправить потенциальный баг репорт разработчику. Если речь о том, чтобы разобраться самому пользователю, то даже большинство ошибок системных вызовов можно свести к нескольким десяткам заготовленных строк с высокой вероятностью, что они более или менее опишут проблему, и самое главное помогут ее решить пользователю.
Здравствуйте, edton, Вы писали:
E>Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>> то неплохо бы вернуть наверх более подробную информацию, которую можно показать пользователю, чтобы он имел более-менее адекватное представление о проблеме.
E>"Подробная информация, которую можно показать пользователю" в целом ограничена количеством заранее заготовленных строк, которые мы показываем в messagebox или еще где, даже если это строки вида "Не удалось открыть файл %s в папке %s потому, что %s" Показывать пользователю что то более сложное чаще всего (от софта и аудитории конечно зависит) не имеет смысла. Пользователю ведь зачем это сообщение — или чтобы разобраться самому или отправить потенциальный баг репорт разработчику. Если речь о том, чтобы разобраться самому пользователю, то даже большинство ошибок системных вызовов можно свести к нескольким десяткам заготовленных строк с высокой вероятностью, что они более или менее опишут проблему, и самое главное помогут ее решить пользователю.
Именно что... Кроме банального "Что-то пошло не так" + guid, что еще разумного в наше время можно сделать?
Ну понятно, по guid где-то должен быть доступен полный лог, с ошибками и т.п.
Здравствуйте, edton, Вы писали:
E>"Подробная информация, которую можно показать пользователю" в целом ограничена количеством заранее заготовленных строк, которые мы показываем в messagebox или еще где, даже если это строки вида "Не удалось открыть файл %s в папке %s потому, что %s"
Совершенно верно. Вот как раз эти %s и нужно вернуть изнутри наружу. Сама форматная строка вполне может однозначно определяться кодом ошибки.
Здравствуйте, so5team, Вы писали:
S>>>Кого-то интересует скорость работы в отладочном режиме?
N>>Во-первых, как уже сказано, и в отладочном режиме скорость может быть важна, и критически важна. И тогда может и отладчик включаться (но лучше — в неинтерактивном режиме, а, например, со скриптами на точки останова). S>Остается позавидовать тем, у кого в Debug режиме производительность достаточная для решения их задач. И кто готов ходить по граблям "в Debug все работает, а в Release какие-то странные вещи происходят" просто потому, что без отладчика ни на что не годен.
Какие у вас основания для подобных домыслов, кроме собственной буйной фантазии?
N>>Во-вторых, в остальном умные вещи пишете, а тут — такую древнюю наркоманию. S>Я тут уже после первого упоминания об отладке реалтайм кода в отладчике перестал всерьез что-либо писать.
Ну вот очень жаль, что вы в ответ на вполне разумные вещи включили дурочку.
Здравствуйте, netch80, Вы писали:
N>>>Во-первых, как уже сказано, и в отладочном режиме скорость может быть важна, и критически важна. И тогда может и отладчик включаться (но лучше — в неинтерактивном режиме, а, например, со скриптами на точки останова). S>>Остается позавидовать тем, у кого в Debug режиме производительность достаточная для решения их задач. И кто готов ходить по граблям "в Debug все работает, а в Release какие-то странные вещи происходят" просто потому, что без отладчика ни на что не годен.
N>Какие у вас основания для подобных домыслов, кроме собственной буйной фантазии?
Ну давайте посмотрим. Режим Debug -- это ведь не только отсутствие оптимизаций со стороны компилятора. Это ведь и выполнение assert-ов, которые могут быть в изобилии разборосаны в коде (причем не столько в вашем собственном, сколько в коде использованных вами сторонних библиотек) + (возможно) дополнительные куски проверок и других форм defensive programming, которые включаются только в Debug режиме (опять же, больше в сторонних библиотеках) + (возможно) специальные отладочные фокусы в STL (вроде STL от MS с дополнительными проверками в итераторах) + (возможно) специальные версии new/delete, которые выполняют дополнительные проверки и/или несколько иначе располагают данные в памяти (добавляют специальные проверочные фрагменты до/после выделенного блока). Все это не может не внести значимый оверхед по сравнению с Release режимом.
Просто для иллюстрации: специально после того как утром прочел ваш ответ прогнал один из простеньких бенчмарков нашего RESTinio. В Debug сборке 50K req/s, в Release 150K req/s. Ну вот нельзя всерьез говорить о важности скорости в Debug-е, если просадка в 3 раза на ровном месте.
Изрядная часть реально сложных багов возникает на максимальных нагрузках при максимальной производительности. Когда минимальные задержки и срабатывают сценарии, о которых разработчик даже никогда не задумывался, а в Debug режиме даже близко к ним подойти не может, потому что скорости тупо не хватает для повторения. Могу только пожелать удачи в борьбе с такими проблемами посредством пошаговой отладки в отладчике.
N>>>Во-вторых, в остальном умные вещи пишете, а тут — такую древнюю наркоманию. S>>Я тут уже после первого упоминания об отладке реалтайм кода в отладчике перестал всерьез что-либо писать.
N>Ну вот очень жаль, что вы в ответ на вполне разумные вещи включили дурочку.
У меня был опыт с реальным временем в прошлом, а сейчас время от времени приходится иметь дело с потоками событий в десятки тысяч в секунду. И когда кто-то мне начинает вещать про полезность отладчика в таких условиях, то я снимаю лапшу с ушей и, если есть настроение, начинаю прикалываться над расказчиками этих удивительных историй. Вот как в данном случае.
Здравствуйте, so5team, Вы писали:
S>Изрядная часть реально сложных багов возникает на максимальных нагрузках при максимальной производительности. Когда минимальные задержки и срабатывают сценарии, о которых разработчик даже никогда не задумывался, а в Debug режиме даже близко к ним подойти не может, потому что скорости тупо не хватает для повторения. Могу только пожелать удачи в борьбе с такими проблемами посредством пошаговой отладки в отладчике.
Бывает так, что в релизе все (в смысле многопоточности) успевают проскочить через проблемное место, а в debug-сборке (именно из за тормозов) не успевают.
---
Бывает еще, что неделю гоняешь автоматизированные тесты — все ок. А потом, случайно решишь повозиться руками — а оно .....ля оказывается валится.
---
В общем, не все так однозначно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, so5team, Вы писали:
N>>>>Во-первых, как уже сказано, и в отладочном режиме скорость может быть важна, и критически важна. И тогда может и отладчик включаться (но лучше — в неинтерактивном режиме, а, например, со скриптами на точки останова). S>>>Остается позавидовать тем, у кого в Debug режиме производительность достаточная для решения их задач. И кто готов ходить по граблям "в Debug все работает, а в Release какие-то странные вещи происходят" просто потому, что без отладчика ни на что не годен.
N>>Какие у вас основания для подобных домыслов, кроме собственной буйной фантазии?
S>Ну давайте посмотрим. Режим Debug -- это ведь не только отсутствие оптимизаций со стороны компилятора. Это ведь и выполнение assert-ов, которые могут быть в изобилии разборосаны в коде (причем не столько в вашем собственном, сколько в коде использованных вами сторонних библиотек) + (возможно) дополнительные куски проверок и других форм defensive programming, которые включаются только в Debug режиме (опять же, больше в сторонних библиотеках) + (возможно) специальные отладочные фокусы в STL (вроде STL от MS с дополнительными проверками в итераторах) + (возможно) специальные версии new/delete, которые выполняют дополнительные проверки и/или несколько иначе располагают данные в памяти (добавляют специальные проверочные фрагменты до/после выделенного блока). Все это не может не внести значимый оверхед по сравнению с Release режимом.
S>Просто для иллюстрации: специально после того как утром прочел ваш ответ прогнал один из простеньких бенчмарков нашего RESTinio. В Debug сборке 50K req/s, в Release 150K req/s. Ну вот нельзя всерьез говорить о важности скорости в Debug-е, если просадка в 3 раза на ровном месте.
Вот! Вы только подтвердили, что я говорю.
Вы выставили сами себе два режима — debug и release. Вы навесили на них кучу всякого. Типа, debug у вас с ассертами, а релиз — без. Дебаг без оптимизации, а релиз — с максимальной оптимизацией, и тому подобное. Я понимаю, что в какой-то мере это определяется внешними условиями типа
>> роде STL от MS с дополнительными проверками в итераторах) + (возможно) специальные версии new/delete
но зачем вы целиком этому подчиняетесь? Что мешает включить голову и самому управлять, что нужно?
Те же ассерты — какая-то часть из них должна остаться и в релизе.
Какая-то должна начать писать логи и трейсы вместо полного вышибания.
И прочая и прочая.
Есть сравнение по этому поводу, которому уже надцать лет, но я забыл автора: подобные методы это всё равно что сначала вести автомобиль со скоростью пешехода, а затем гонять на всех газах, не пристёгиваясь. Вы вот ровно такого горе-водителя и описываете.
S>Изрядная часть реально сложных багов возникает на максимальных нагрузках при максимальной производительности. Когда минимальные задержки и срабатывают сценарии, о которых разработчик даже никогда не задумывался, а в Debug режиме даже близко к ним подойти не может, потому что скорости тупо не хватает для повторения. Могу только пожелать удачи в борьбе с такими проблемами посредством пошаговой отладки в отладчике.
И ещё раз: откуда вы взяли про пошаговую отладку? Ваши представления об отладчиках застыли на уровне каменного века? Ну так узнайте хоть что-то про современные инструменты.
В качестве простейшего примера: отладчики могут поддерживать скрипты точек останова, которые будут писать, если нужно, детали обстановки, или модифицировать её по условию, и тут же запускать код дальше.
Да даже дополнительные логи без перекомпиляции — уже прогресс — и это делается без проблем.
N>>>>Во-вторых, в остальном умные вещи пишете, а тут — такую древнюю наркоманию. S>>>Я тут уже после первого упоминания об отладке реалтайм кода в отладчике перестал всерьез что-либо писать. N>>Ну вот очень жаль, что вы в ответ на вполне разумные вещи включили дурочку. S>У меня был опыт с реальным временем в прошлом, а сейчас время от времени приходится иметь дело с потоками событий в десятки тысяч в секунду. И когда кто-то мне начинает вещать про полезность отладчика в таких условиях, то я снимаю лапшу с ушей и, если есть настроение, начинаю прикалываться над расказчиками этих удивительных историй. Вот как в данном случае.
Вся ваша "лапша" на ушах — собственного изготовления, и таки да, чтобы начать слушать, вам надо её снять с ушей.
Здравствуйте, so5team, Вы писали:
S>Все это не может не внести значимый оверхед по сравнению с Release режимом.
Так оно и вносит, с этим никто не спорит. Вы кому возражаете-то?
Из того, что код реалтаймовый, ни разу не вытекает, что он со всей этой отладочной лабудой непременно потеряет возможность успевать за процессом. Хотя и такое бывает.
S>В Debug сборке 50K req/s, в Release 150K req/s. Ну вот нельзя всерьез говорить о важности скорости в Debug-е, если просадка в 3 раза на ровном месте.
Каким образом это может автоматически снять вопрос о важности скорости? Если для задач, которые решает ваш код, достаточно обрабатывать, например, 20K req/s, то какие проблемы может создать отсутствие оптимизации в отладочных сборках? А если требуется обрабатывать 200K req/s, то этот код вообще не годится, хоть отладочный, хоть релизный. Где логика?
S>Изрядная часть реально сложных багов возникает на максимальных нагрузках при максимальной производительности. Когда минимальные задержки и срабатывают сценарии, о которых разработчик даже никогда не задумывался, а в Debug режиме даже близко к ним подойти не может, потому что скорости тупо не хватает для повторения. Могу только пожелать удачи в борьбе с такими проблемами посредством пошаговой отладки в отладчике.
Поздравляю, Вы сперва откуда-то взяли, что никто, кроме Вас, не знает о таких сложных багах и не умеет с ними бороться, а затем принялись активно спорить с воображаемым оппонентом. А ведь Вам прямо и подробно описали, что как раз для подобных случаев и нужны выборочные оптимизации, а не тупое деление на "debug" и "release".
S>сейчас время от времени приходится иметь дело с потоками событий в десятки тысяч в секунду. И когда кто-то мне начинает вещать про полезность отладчика в таких условиях
Возможно, Вы удивитесь, но и в таких условиях отладчик (в том числе ручной) бывает полезен. Если действительно не знаете, для чего — могу научить.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Бывает так, что в релизе все (в смысле многопоточности) успевают проскочить через проблемное место, а в debug-сборке (именно из за тормозов) не успевают.
У меня для таких случаев по коду раскиданы небольшие задержки случайной длительности, включаемые параметром компиляции.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>И ещё раз: откуда вы взяли про пошаговую отладку?
ЕМ>Так это я о ней писал. В определенных условиях она наиболее удобна.
Вот именно, что у тебя "в определённых условиях" и ты знаешь, что бывает иначе. А so5team вообще никакого больше варианта не слышит.
Здравствуйте, netch80, Вы писали:
N>И ещё раз: откуда вы взяли про пошаговую отладку? Ваши представления об отладчиках застыли на уровне каменного века? Ну так узнайте хоть что-то про современные инструменты. N>В качестве простейшего примера: отладчики могут поддерживать скрипты точек останова, которые будут писать, если нужно, детали обстановки, или модифицировать её по условию, и тут же запускать код дальше. N>Да даже дополнительные логи без перекомпиляции — уже прогресс — и это делается без проблем.
о каких инструментах речь?
если о студии, то там это очень сильно тормозит исполнение программы (порою бывает проще вставить явный вывод или проверку условий)
Здравствуйте, night beast, Вы писали:
N>>И ещё раз: откуда вы взяли про пошаговую отладку? Ваши представления об отладчиках застыли на уровне каменного века? Ну так узнайте хоть что-то про современные инструменты. N>>В качестве простейшего примера: отладчики могут поддерживать скрипты точек останова, которые будут писать, если нужно, детали обстановки, или модифицировать её по условию, и тут же запускать код дальше. N>>Да даже дополнительные логи без перекомпиляции — уже прогресс — и это делается без проблем.
NB>о каких инструментах речь? NB>если о студии, то там это очень сильно тормозит исполнение программы (порою бывает проще вставить явный вывод или проверку условий)
Не, ну с перекомпиляцией, понятно, почти наверняка быстрее бегать будет (а вот можно ли так перекомпилировать и сколько это займёт — тут и начинаются загвоздки). Но всё равно даже с остановками и переключениями быстрее, чем человек — и это уже то, о чём я говорю.
Виндовую специфику я тут не знаю. Под Linux или чем-то похожим мне нормально сработало.
Здравствуйте, netch80, Вы писали:
N>но зачем вы целиком этому подчиняетесь? Что мешает включить голову и самому управлять, что нужно?
Например то, что 95% кода от меня не зависит. Если кто-то хочет вручную управлять ассертами в потрохах STL или Asio -- флаг в руки.
N>Те же ассерты — какая-то часть из них должна остаться и в релизе.
Ассерты в релизе? Это либо какая-то лютая хрень, либо не ассерты, а часть логики кода (например, часть defensive programming) которая отвечает за проверку контрактов и/или инвариантов. Но эта часть не является зависящими от NDEBUG ассертами.
N>Какая-то должна начать писать логи и трейсы вместо полного вышибания.
Опять же, это часть логики, от Debug/Release не зависит.
N>Есть сравнение по этому поводу, которому уже надцать лет, но я забыл автора: подобные методы это всё равно что сначала вести автомобиль со скоростью пешехода, а затем гонять на всех газах, не пристёгиваясь. Вы вот ровно такого горе-водителя и описываете.
Нет, я говорю лишь о том, что когда ставят вопрос о максимальной скорости, то показатели заведомо заторможенного кода не должны никого волновать. Ну или скорость вообще не нужна от слова совсем.
Если у вас есть примеры того, где важна максимальная скорость кода, собранного в Debug режиме, то с интересом послушаю.
N>И ещё раз: откуда вы взяли про пошаговую отладку? Ваши представления об отладчиках застыли на уровне каменного века? Ну так узнайте хоть что-то про современные инструменты.
Вывел это из контекста разговора с ТС-ом.
N>В качестве простейшего примера: отладчики могут поддерживать скрипты точек останова, которые будут писать, если нужно, детали обстановки, или модифицировать её по условию, и тут же запускать код дальше.
Если ТС апеллирует к реал-тайму, то даже такие продвинутые отладчики в условиях реал-тайма идут лесом. Ну или у реал-тайма там время отклика секундное.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так оно и вносит, с этим никто не спорит. Вы кому возражаете-то?
Возражения вы где увидели?
ЕМ>Из того, что код реалтаймовый, ни разу не вытекает, что он со всей этой отладочной лабудой непременно потеряет возможность успевать за процессом. Хотя и такое бывает.
Если у вас скорости такие, что вы укладываетесь в дедлайны даже в Debug режиме, то ваша трогательная забота о накладных расходах выглядит весьма странно.
S>>В Debug сборке 50K req/s, в Release 150K req/s. Ну вот нельзя всерьез говорить о важности скорости в Debug-е, если просадка в 3 раза на ровном месте.
ЕМ>Каким образом это может автоматически снять вопрос о важности скорости?
Автоматическим образом. Если вас устраивает 50K req/s, то заботиться о методах, которые позволяют достичь 150K req/s уже не нужно. В принципе. И освободившееся время/ресурсы можно потратить на что-то более полезное.
EM>А если требуется обрабатывать 200K req/s, то этот код вообще не годится, хоть отладочный, хоть релизный. Где логика?
В своих рассуждениях вы сами, пожалуйста, логику ищите. Я не собираюсь искать то, чего нет.
Здравствуйте, so5team, Вы писали:
S>Ассерты в релизе?
Почему нет?
S>Но эта часть не является зависящими от NDEBUG ассертами.
Правильно, она должна управляться отдельными параметрами.
N>>Какая-то должна начать писать логи и трейсы вместо полного вышибания. S>Опять же, это часть логики, от Debug/Release не зависит.
Почему? Даже если конфигураций всего две (Debug/Release), то какая-то регистрация может быть безусловной, а остальная добавляться только в Debug. Но еще лучше вынести все это в независимые параметры. Тогда любую конфигурацию можно собрать с любым набором параметров, и от Debug/Release остаются только имена.
Параметры можно задавать в заголовках, если компилятор поддерживает управление нужной оптимизацией, или в Property Sheets для студии.
S>я говорю лишь о том, что когда ставят вопрос о максимальной скорости, то показатели заведомо заторможенного кода не должны никого волновать.
Кроме черного и белого, есть даже оттенки серого, не говоря уже о других цветах.
S>даже такие продвинутые отладчики в условиях реал-тайма идут лесом. Ну или у реал-тайма там время отклика секундное.
WinDbg выполняет перехват и простые скрипты за доли миллисекунды. Если Вы не считаете это реалтаймом, то хотелось бы услышать доводы, отличные от сугубо личного мнения.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Ассерты в релизе?
ЕМ>Почему нет?
По определению.
N>>>Какая-то должна начать писать логи и трейсы вместо полного вышибания. S>>Опять же, это часть логики, от Debug/Release не зависит.
ЕМ>Почему? Даже если конфигураций всего две (Debug/Release), то какая-то регистрация может быть безусловной, а остальная добавляться только в Debug. Но еще лучше вынести все это в независимые параметры. Тогда любую конфигурацию можно собрать с любым набором параметров, и от Debug/Release остаются только имена.
Опять же, по определению. Если у вас больше конфигураций сборки, нежели Debug и Release, то тогда и говорите о других конфигурациях, а не о Debug и Release.
S>>я говорю лишь о том, что когда ставят вопрос о максимальной скорости, то показатели заведомо заторможенного кода не должны никого волновать.
ЕМ>Кроме черного и белого, есть даже оттенки серого, не говоря уже о других цветах.
Это в разговоре о скорости кода у вас есть оттенки? Ну ОК, чего только не бывает.
ЕМ>WinDbg выполняет перехват и простые скрипты за доли миллисекунды. Если Вы не считаете это реалтаймом, то хотелось бы услышать доводы, отличные от сугубо личного мнения.
Ну а я бы еще послушал афигительные истории про пошаговую отладку в реал-тайме. Веселит, знаете ли.
Хотя в современных реалиях вероятность нехватки памяти для работы моего кода можно считать строго нулевой. 
