мне кажется все таки c VT10 надежней, вам придется и R133 уменьшить до минимума, чтобы лог 0, был "чище". А в этом случае проц сможет "продавить" состояние на D у триггера
частично согласен с вами, предполагаю что подобные кейсы будут основываться на монадах или подобном. Но тогда все равно добавится один лишний бранч, условие для дальнейшего выполнения кода, если есть обьект или если нет обьекта.
Я же имел ввиду проверку на этапе компиляции, и если есть вероятность что обьект может отсутствовать, то проверку и бранчевание сделать один раз, например при получении обьекта. А все дальнейшие обработки производить с гарантией что обьект обязательно существует.
почему по вашему нельзя 0 вернуть при NULL? strlen не отвечает же на вопрос существования строки, а только ее длины. И если строки нет, то и длина получается ноль.
когда-то давно практиковал обучение пайки новых работников, путем распаивания старых плат. Два в одном, и навык и восстановление ассортимента радиодеталей.
напряжение менее половины питания
и заблокировали нажатие кнопки
достаточно еще одного pullup резистора дальше, и "нуля" не станет
мне кажется все таки c VT10 надежней, вам придется и R133 уменьшить до минимума, чтобы лог 0, был "чище". А в этом случае проц сможет "продавить" состояние на D у триггера
скорее всего подгонка сопротивления для таймера (Если же кнопку отпустить раньше, то батарея конденсаторов не успеет зарядиться.)
:) если есть возможность использовать чтото из std:: то можно и не париться, а использовать new и exceptions.
nullable типы нужны для подобного, один раз проверил и все.
уже и пропозал есть https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004
частично согласен с вами, предполагаю что подобные кейсы будут основываться на монадах или подобном. Но тогда все равно добавится один лишний бранч, условие для дальнейшего выполнения кода, если есть обьект или если нет обьекта.
Я же имел ввиду проверку на этапе компиляции, и если есть вероятность что обьект может отсутствовать, то проверку и бранчевание сделать один раз, например при получении обьекта. А все дальнейшие обработки производить с гарантией что обьект обязательно существует.
почему по вашему нельзя 0 вернуть при NULL?
strlen не отвечает же на вопрос существования строки, а только ее длины. И если строки нет, то и длина получается ноль.
хорошим подспорьем был бы атрибут nullable для переменных, и проверка на этапе компиляции.
для перфоманса может и не нужно проверять в цикле?
для меня оправдание небходимости/полезности ООП состоит в обязательном покрытии кода юнит-тестами и лень писать однотипный код более двух раз
а разве недостаточно что в компиляторах (gcc/clang) есть флаг -ftrivial-auto-var-init=zero?
когда-то давно практиковал обучение пайки новых работников, путем распаивания старых плат. Два в одном, и навык и восстановление ассортимента радиодеталей.
а содержимое буфера теперь всегда одинаковое?
попробуйте запустить этот код на какой-нибудь железке, без внешней сети и внешних сенсоров, и желательно чтобы была однопоточная.
спасибо за развернутый ответ, т.е. зеленый необязательный:)
Можете привести пример какого-либо сигнала, который можно пропустить, но нельзя ложно включить?
Если можно безболезненно пропустить, то зачем он вообще нужен?
а если у реле контакты залипнут?