Огого! Спасибо большое за подробный ответ!
Не уверен, что все понял, к сожалению, очень уж синтаксис непривычный.
У меня есть ощущение, что что-то частично подобное можно сделать на шаблонах С++, скажем, у std::array размер — шаблонный параметр, довольно легко написать функцию, которая складывает только массивы одной длины.
Но вот кусок, который родит нужный класс в рантайме в зависимости от прочитанной из файла длины — вот тут сходу не получается.
Собственно, это ключевая фича зависимых типов — можно ли выражать терм-левел зависимости в типах, которые могут быть вычислены лишь во время выполнения, или нет.
А вас не затрудник немножко разжевать это для несведующих?
Как это происходит?
Насколько я понимаю, это иллюстрация того, что вероятность ошибки в коде гораздо выше вероятности ложного срабатывания анализатора.
И первым делом надо внимательно код почитать, в препроцессорный вывод посмотреть, а уже потом писать в техподдержку о ложном срабатывании.
Спасибо автору за свежий взгляд, но мне кажется, что в тексте повторяется та же ошибка, которую совершают апологеты конкретных диет, систем упражнений и тому подобного — чрезмерное упрощение. Очень хочется найти какую-то одну причину. Максимум три-четыре.
А практика между тем показывает, что диетология — это очень, очень сложно, запутанно, многофакторно. И изучается тяжело.
Дилетантский вопрос: если аккумулятор в нужном габарите выдает слишком низкое напряжение (особенно, если не на порядок), почему не поставить повышающий преобразователь? Неужели потери в нем настолько сильны, что сводят все преимущество в емкости на нет?
Не, как обычные пользователи жили — понятно, а вот как без числа пи жили всякие std::sph_bessel или std::cauchy_distribution (всмысле, сам библиотечный код), если там в исходной формуле число пи?
Неужели тоже константу заводили каждый раз?
Насчет корня из трех не знаю, но корень из двух попадается в формулах очень часто.
Мне больше интересно, как вся математика до сих пор жила без числа "пи", в С++11 же кучу тригонометрии и распределений насовали.
Или, например, если переполнение вызвано прерыванием и приведет к hard fault'у до проверки. Вариантов достаточно много.
Разумеется, проверки — вещь не бесполезная, просто нужно осознавать, что это не панацея.
По-моему, "грепнуть по ансейфу" — это, все же, чуть меньший миф, чем плюсовое "грепнуть по const_cast/reinterpret_cast".
Огого! Спасибо большое за подробный ответ!
Не уверен, что все понял, к сожалению, очень уж синтаксис непривычный.
У меня есть ощущение, что что-то частично подобное можно сделать на шаблонах С++, скажем, у std::array размер — шаблонный параметр, довольно легко написать функцию, которая складывает только массивы одной длины.
Но вот кусок, который родит нужный класс в рантайме в зависимости от прочитанной из файла длины — вот тут сходу не получается.
А вас не затрудник немножко разжевать это для несведующих?
Как это происходит?
st-link вроде не умеет шить 1986ВЕ1
Насколько я понимаю, это иллюстрация того, что вероятность ошибки в коде гораздо выше вероятности ложного срабатывания анализатора.
И первым делом надо внимательно код почитать, в препроцессорный вывод посмотреть, а уже потом писать в техподдержку о ложном срабатывании.
В Scala; нужно ставить только если вы хотите несколько выражений написать в пределах одной строки, а в остальном хватает просто переноса.
Наверное, следует упомянуть, что мониторинг компиляции может пропускать отдельные запуски компилятора, если они завершаются слишком быстро.
Так понятнее, спасибо.
Простите, непонятно, как это связано с моим вопросом.
Ну, окей. Просто статью вы вроде как свели к выводу о локальном гипертонусе мышц; я это воспринял как очередную единственно верную истинную причину.
Спасибо автору за свежий взгляд, но мне кажется, что в тексте повторяется та же ошибка, которую совершают апологеты конкретных диет, систем упражнений и тому подобного — чрезмерное упрощение. Очень хочется найти какую-то одну причину. Максимум три-четыре.
А практика между тем показывает, что диетология — это очень, очень сложно, запутанно, многофакторно. И изучается тяжело.
Дилетантский вопрос: если аккумулятор в нужном габарите выдает слишком низкое напряжение (особенно, если не на порядок), почему не поставить повышающий преобразователь? Неужели потери в нем настолько сильны, что сводят все преимущество в емкости на нет?
Самому написать? Или библиотеке?
Говорят,
4*atan(1)точнее выходит :)Капец.
Не, как обычные пользователи жили — понятно, а вот как без числа пи жили всякие
std::sph_besselилиstd::cauchy_distribution(всмысле, сам библиотечный код), если там в исходной формуле число пи?Неужели тоже константу заводили каждый раз?
Насчет корня из трех не знаю, но корень из двух попадается в формулах очень часто.
Мне больше интересно, как вся математика до сих пор жила без числа "пи", в С++11 же кучу тригонометрии и распределений насовали.
Господи, дождались! В С++20 будет число пи :)
Или, например, если переполнение вызвано прерыванием и приведет к hard fault'у до проверки. Вариантов достаточно много.
Разумеется, проверки — вещь не бесполезная, просто нужно осознавать, что это не панацея.
Вроде по-умолчанию нигде дополнительный стек не выделяется. И на практике стек прерывания будет просто стеком прерываемой задачи.